SÉCURITÉ APPLICATIVE Le bon outil, la bonne

administration

Jérôme CLAUZADE Product Management Director

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…

OÙ PLACER LE WAF ?

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…

PRENONS L’EXEMPLE D’UN DOCUMENT XML CHIFFRÉ

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 !

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é

CARTOGRAPHIE RESEAU APPLICATIVE

accept SQL injection accept Command injection accept any HTTP based exploit…

+ Les murs en place ne sont pas assez hauts

+ Les flux HTTP sont (souvent) cartographiés…

+ … mais pas qualifiés

+ … et rarement en interne

CARTOGRAPHIE WEB SERVICES ??

accept SQL injection accept Command injection accept any XML/JSON based exploit…

+ 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

QUI EXPLOITE LE WAF ?

SÉCURITÉ APPLICATIVE ET PROCESS METIER

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 !

LE CONSTAT

✘1 produit

✘1 personne

✘1 endroit

+ La sécurité applicative ne peut reposer sur :

ET DONC ?

??

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

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

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

USUAL PRODUCTS

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

INTELLIGENCE APPLICATIVE

>> 95% de l’intelligence du WAF est « applicative »

Hémisphère Applicatif Listes d’URL

Journalisation Faux positifs

Routage applicatif Etc.

Hémisphère Sécurité Détection d’intrusion

Contrôle d’accès Audit de sécurité

Disponibilité de service Etc.

Zone réseau Déclaration d’IP

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

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

EXEMPLES DE SERVICES

EXEMPLES DE SERVICES

Je mets à jour l’application

Je valide la conformité de ces nouvelles URL

Intégration des nouvelles URL dans la configuration

API

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

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

POUR TOUTES LES ARCHITECTURES

AU PLUS TÔT

+ Le WAF peut jouer un rôle dès le développement des

applications

Exemple : OpenSAMM

EXEMPLE OPENSAMM

Pourquoi ?

+ Identifier les risques applicatifs

+ Réduire la surface d’attaque

+ Optimiser le coût de la sécurité

+ Industrialiser la protection

Design Review

Environment Hardening

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 !)

CONTACTS Jérôme Clauzade jerome.clauzade@bee-ware.net

Service commercial +33 (0) 1 74 90 50 96 sales@bee-ware.net

Bee Ware 20 rue Billancourt 92100 Boulogne Billancourt +33 (0)1 74 90 50 90 contact@bee-ware.net

+ D’INFOS