Non, ce n'est pas mon chien qui vous parle, rappelez vous, lui, c'est un expert en sécurité physique. Or de physique, nous n'en parlerons pas ce jour. Peut être demain ?
Nous allons nous élever, non pas par la méditation transcendantale, mais dans les couches ISO, et aller tutoyer les sommets de la sécurité applicative. Enfin, me direz vous, la sécurité des applications est fondamentale, et tout ce que l'on peut faire par ailleurs ne sert pas à grand-chose si l'application comporte quelques failles exploitables. Je vous le rappelle l'application est la dernière couche du modèle ISO, et est, par conséquent, la plupart des cas, la seule couche perçue par l'utilisateur ou le pirate, c'est selon. D'où la nécessité de protéger l'application. Or, il existe une méthode pour sécuriser celle-ci : la programmation sécurisée. Et c'est la seule méthode, connue de tout le monde, mais que personne n'applique réellement. Alors que faire, se taper la tête contre les murs, et attendre que cela passe... C'est une méthode qui peut faire un peu mal... Une autre existe, un peu plus indolore, le WAF, ou plutôt le Web Application Firewall, puisque maintenant la plupart des applications sont en mode WEB ou en passe de l'être.
Mais, il faut se méfier, il y a WAF et WAF. Il y deux chemins, jeune scarabée pour atteindre la sécurité des applications. Le premier d'apparition relativement récente, est simple, et plein de lumières pour attirer la chaland, consiste à prendre la technologie des IPS (Intrusion Prevention System), et d'y rajouter quelques règles (enfin pas mal) pour « gérer » la couche applicative, type attaque buffer overflow, cross script scripting, SQL injection, et autres joyeusetés. A écouter les disciples de cette voie, cette technologie est simple à mettre en œuvre et presque exhaustive grâce à l'analyse comportementale. Pour le premier point, ils ont raison. Pour le second, c'est un peu plus nuancé, en fait non... Ils ne doivent pas savoir comment on attaque une application grâce aux différentes techniques citées plus haut. Jamais une technologie à base de signatures (et on l'a vu pour les anti virus, je vous le rappelle) ne peut vous protéger efficacement. Pour quoi, simplement, parce que les signatures ont toujours un bus de retard (dans le meilleur des cas). Il faudrait des dizaines de milliers de signatures, et encore, pour éviter des attaques simples, mais canonicalisées (c'est-à-dire que l'on modifie la signature de l'attaque en utilisant des combinaisons de code hexadécimal, octal, ASCII, ...avec cette méthode, il existe des centaines de façons d'écrire SCRIPT, donc des centaines de signatures d'attaques éventuelles qui n'existent bien sûr pas). Mais ces disciples sûrs d'eux, diront qu'ils ont l'arme : l'analyse comportementale. C'est vrai, une attaque de type deni de service sera vue (fantastique exploit !), mais certainement pas une attaque ciblée qui saura resté sous le radar, et ne pourra être vue que par corrélation d'événements (et encore !). Ce type de voie facile pour accéder à la sécurité applicative (que l'on atteindra ni verra jamais par cette méthode) peut en tenter plus d'un. Et c'est peut être une solution à mettre en œuvre pour des applications non critiques.
La seconde voie est longue et obscure, mais permet de s'approcher du Nirvana sans toutefois l'atteindre (rappelons que la sécurité absolue n'existe pas), elle est à base de technologie de reverse proxy, c'est-à-dire que l'on contrôle la plupart des saisies et écrans. Dura Securitax sed Securitax. La route est longue et tortueuse vers la sécurité suprême, mais elle permet, sans trop réécrire l'applicatif, d'obtenir une bonne sécurité convenant à des applications critiques.
Alors faites votre choix. Je n'ai pas cité d'éditeurs, et c'est normal... n'ayant pas touché de chèques suffisamment importants sur mon compte dont vous trouverez les références dans des articles précédents.
Nous allons nous élever, non pas par la méditation transcendantale, mais dans les couches ISO, et aller tutoyer les sommets de la sécurité applicative. Enfin, me direz vous, la sécurité des applications est fondamentale, et tout ce que l'on peut faire par ailleurs ne sert pas à grand-chose si l'application comporte quelques failles exploitables. Je vous le rappelle l'application est la dernière couche du modèle ISO, et est, par conséquent, la plupart des cas, la seule couche perçue par l'utilisateur ou le pirate, c'est selon. D'où la nécessité de protéger l'application. Or, il existe une méthode pour sécuriser celle-ci : la programmation sécurisée. Et c'est la seule méthode, connue de tout le monde, mais que personne n'applique réellement. Alors que faire, se taper la tête contre les murs, et attendre que cela passe... C'est une méthode qui peut faire un peu mal... Une autre existe, un peu plus indolore, le WAF, ou plutôt le Web Application Firewall, puisque maintenant la plupart des applications sont en mode WEB ou en passe de l'être.
Mais, il faut se méfier, il y a WAF et WAF. Il y deux chemins, jeune scarabée pour atteindre la sécurité des applications. Le premier d'apparition relativement récente, est simple, et plein de lumières pour attirer la chaland, consiste à prendre la technologie des IPS (Intrusion Prevention System), et d'y rajouter quelques règles (enfin pas mal) pour « gérer » la couche applicative, type attaque buffer overflow, cross script scripting, SQL injection, et autres joyeusetés. A écouter les disciples de cette voie, cette technologie est simple à mettre en œuvre et presque exhaustive grâce à l'analyse comportementale. Pour le premier point, ils ont raison. Pour le second, c'est un peu plus nuancé, en fait non... Ils ne doivent pas savoir comment on attaque une application grâce aux différentes techniques citées plus haut. Jamais une technologie à base de signatures (et on l'a vu pour les anti virus, je vous le rappelle) ne peut vous protéger efficacement. Pour quoi, simplement, parce que les signatures ont toujours un bus de retard (dans le meilleur des cas). Il faudrait des dizaines de milliers de signatures, et encore, pour éviter des attaques simples, mais canonicalisées (c'est-à-dire que l'on modifie la signature de l'attaque en utilisant des combinaisons de code hexadécimal, octal, ASCII, ...avec cette méthode, il existe des centaines de façons d'écrire SCRIPT, donc des centaines de signatures d'attaques éventuelles qui n'existent bien sûr pas). Mais ces disciples sûrs d'eux, diront qu'ils ont l'arme : l'analyse comportementale. C'est vrai, une attaque de type deni de service sera vue (fantastique exploit !), mais certainement pas une attaque ciblée qui saura resté sous le radar, et ne pourra être vue que par corrélation d'événements (et encore !). Ce type de voie facile pour accéder à la sécurité applicative (que l'on atteindra ni verra jamais par cette méthode) peut en tenter plus d'un. Et c'est peut être une solution à mettre en œuvre pour des applications non critiques.
La seconde voie est longue et obscure, mais permet de s'approcher du Nirvana sans toutefois l'atteindre (rappelons que la sécurité absolue n'existe pas), elle est à base de technologie de reverse proxy, c'est-à-dire que l'on contrôle la plupart des saisies et écrans. Dura Securitax sed Securitax. La route est longue et tortueuse vers la sécurité suprême, mais elle permet, sans trop réécrire l'applicatif, d'obtenir une bonne sécurité convenant à des applications critiques.
Alors faites votre choix. Je n'ai pas cité d'éditeurs, et c'est normal... n'ayant pas touché de chèques suffisamment importants sur mon compte dont vous trouverez les références dans des articles précédents.
_