1. SÉCURITÉ APPLICATIVE
Le bon outil, la bonne
administration
Jérôme CLAUZADE
Product Management Director

2. A L’ORIGINE…
+ Le WAF a comblé une faiblesse des pare-feux réseau
+ On l’a déployé derrière eux
+ Les applications web étaient donc protégées de manière
empirique
+ Malheureusement, c’est
toujours le cas…

3. OÙ PLACER LE WAF ?

4. EN DMZ… OU PAS…
+ Nécessaire mais loin d’être suffisant car…
+ Un équipement en DMZ ne peut pas tout constater ni tout
arrêter…

5. PRENONS L’EXEMPLE D’UN DOCUMENT XML
CHIFFRÉ

6. UN RISQUE D’ATTAQUE
+ Le pare-feu réseau va faire son travail de filtrage de ports
+ Il n’est pas possible de laisser dans la DMZ les clefs privées
nécessaires au déchiffrement du message XML
+ Le pare-feu applicatif situé en DMZ se retrouve donc dans
l’incapacité total de faire son travail…
+ Il va donc transmettre en interne des messages qui sont
potentiellement porteurs de contenus offensifs !

7. DÉPLOYER PLUSIEURS INSTANCES DU WAF
+ Il est nécessaire de passer par une deuxième instance du
pare-feu applicatif, située en interne dans une zone protégée
+ Il sera alors possible
de déployer les clefs
de chiffrement en
toute sécurité

8. CARTOGRAPHIE RESEAU APPLICATIVE
+
+
+
+
Les murs en place ne sont pas assez hauts
Les flux HTTP sont (souvent) cartographiés…
… mais pas qualifiés
… et rarement en interne
accept SQL injection
accept Command injection
accept any HTTP based exploit…

9. CARTOGRAPHIE WEB SERVICES ??
+ Il faut pouvoir analyser les documents
+ A l’intérieur des requêtes HTTP
+ … avec les ressources nécessaires
Ressources = Connaissances
+ moyens techniques
+ moyens cryptographiques
accept SQL injection
accept Command injection
accept any XML/JSON based exploit…

10. QUI EXPLOITE LE WAF ?

11. SÉCURITÉ APPLICATIVE ET PROCESS METIER

12. LES LIMITES DE L’ADMINISTRATION RÉSEAU
+ Historiquement, le pare-feu applicatif est à la charge de
l’administrateur réseaux
+ Mais de nouvelles problématiques viennent agrandir son
spectre fonctionnel
+ … Les limites de l’administrateur vont vite être atteintes !

13. LE CONSTAT
+ La sécurité applicative ne peut reposer sur :
✘1 produit
✘1 personne
✘1 endroit

14. ??
ET DONC ?

15. Le pare-feu applicatif doit être capable d’intercepter et
d’analyser tous les flux (internes, inter-applicatifs, mobiles,
etc.)

16. Il faut donc un produit facilement administrable et facilement
déployable

17. ET DONC…?
+ Bee Ware a conçu un mécanisme de déploiement
automatisé, capable de piloter un grand nombre de
machines
+ Point central de configuration
+ Gain de temps
+ Il est également possible de piloter l’ensemble des tâches
(administration, supervision, configuration) grâce aux API

18. USUAL PRODUCTS
+ Plus on s’éloigne du réseau, plus le rôle de l’administrateur
réseau diminue…

19. INTELLIGENCE APPLICATIVE
>> 95% de l’intelligence du WAF est « applicative »
Hémisphère Sécurité
Détection d’intrusion
Contrôle d’accès
Audit de sécurité
Disponibilité de service
Etc.
Hémisphère Applicatif
Listes d’URL
Journalisation
Faux positifs
Routage applicatif
Etc.
Zone réseau
Déclaration d’IP

20. AU DELÀ DU PRODUIT
+ S’affranchir des contraintes matérielles
• S’adapter à des infrastructures élastiques
• Supporter les hyperviseurs du marché
+ Permettre le suivi de la consommation
• Métriques d’allocation et d’utilisation des ressources
• Gestion flottante des licences
+ Adapter le management de la solution
• Autoriser le management centralisé ou dédié
• Faciliter les audits

21. SÉCURITÉ APPLICATIVE ET PROCESS METIER
+ Les différentes entités auront à leur disposition un
ensemble de services qui ne passera plus par
l’administrateur réseau mais qui sera directement
accessible dans
le produit au
travers d’API

22. EXEMPLES DE SERVICES

23. EXEMPLES DE SERVICES
Je mets à jour
l’application
Je valide la conformité
de ces nouvelles URL
API
Intégration des nouvelles URL dans
la configuration
Mise à jour de la configuration de
sécurité et application de celle-ci
Le WAF s’intègre dans les processus métier et non l’inverse

24. DU PRODUIT VERS LE SERVICE
Fournir de multiples interfaces dédiées pour la
configuration, la supervision, l’audit, etc.
Chaque fonctionnalité doit être invocable comme
un service, avec autorisation et trace
Les clients ne doivent utiliser que ce dont ils ont
besoin, et payer uniquement ce qu’ils sécurisent

25. POUR TOUTES LES ARCHITECTURES

26. AU PLUS TÔT
+ Le WAF peut jouer un rôle dès le développement des
applications
Exemple : OpenSAMM

27. EXEMPLE OPENSAMM
Pourquoi ?
+ Identifier les risques applicatifs
+ Réduire la surface d’attaque
+ Optimiser le coût de la sécurité
+ Industrialiser la protection
Environment
Hardening
Design
Review

28. CONCLUSION
L’évolution de la sécurité applicative passe par une
refonte du rôle du WAF
Le WAF n’est pas un module de pare-feu ou de
répartiteur de charge
La clé est l’adaptation aux processus métier
C’est possible ! (Pensez API !)

29. CONTACTS
Jérôme Clauzade
Bee Ware
jerome.clauzade@bee-ware.net
20 rue Billancourt
92100 Boulogne Billancourt
Service commercial
+33 (0)1 74 90 50 90
contact@bee-ware.net
+33 (0) 1 74 90 50 96
sales@bee-ware.net

30. + D’INFOS