@Nicob : on se verra tous sur Rennes je pense, enfin j’espère Reste à remettre un visage sur les pseudos !

Je viens juste de passer par l’étape "Validation de la note de frais" et c’est clair que le contrôleur de gestion a tiré une drôle de gueule en voyant l’intitulé de l’achat ;-))

En ce qui concerne les SIM, je dois avouer que ceux que j’ai vu tourner (mon ancien employeur en éditant un) permettent enfin d’envisager l’administration d’IDS de manière réaliste et une vraie pertinence côté alertes de sécurité. Et amaha, un IDS tout seul dans son coin ne sert à rien, si ce n’est à fournir du job aux pauvres gars chargés du tuning …

Bon, on se verra tous IRL au SSTIC, comme d’habitude, non ?

@ Sid : Exact. Ma réflexion allait dans un autre sens en fait : L’idée n’est pas de reporter les comportements "déviants" mais de les identifier : Partons du principe que 70% de mes problèmes viennent de l’humain et que proportionnellement j’ai 90% de users finaux. Suis je capable en temps réel d’identifier des comportements anormaux sur mes postes de travail users ? (Que fait on dans les grandes isntitutions lorsque l’on durcit les pc avec des images types ? On limite voire, on supprime les comportements déviants de users. (hors admin)) Aujourd’hui ne peut on pas envisager de trasférer les ressources utilisées à loguer tous les comportements vers un système qui tracerait des activités déviantes (sortant de l’ordianire) et 1/ identifier les personnes à risque , 2/ les tracer 3/ne loguer que celles ci.
Je suis persuadé que je suis capable de réduire mes ressources de 50% et utiliser une partie des autres ressources à effectuer du controle et non plus de la surveillance. (qui reste cependant nécessaire).

Puisque j’apprécie les analogies et que Buno les aime aussi :

Aujourd’hui je fais souvent du 100% ressources dédiées à mes policiers sur le terrain. (prévention, répression, controles, etc…)
Ne peut on pas envisager de transférer 50% des ressources vers un service qui s’apparenterait à de l’identification des personnes à risques ? : un service de renseignements généraux ou de protection du territoire. => ce qui,vous l’aurez compris, existe IRL mais dans notre joli monde de la SSI.
Un service d’identification des personnes à risques ou comportement déviant.

Mon argumentaire n’est pas encore rodé et je vous le soumets tel qu’il me vient. j’en reste au stade de réflexion. (et critiques;-)

a suivre…

Pour les anglophiles, le lien que tu mentionnes est à lire absolument, c’est une très bonne explication en effet de la différence de qualité des IDPS.

Je connaissais pas l’acronyme SIEM (Security Incident Event Management, c’est bien ça ?) En gros, un corrélateur ?

Un NIDS récolte également des informations qui seront utiles lors d’analyses à froid ou d’investigations (qu’on pourra appeler network forensics si on veut ). On y retrouve des infos sympa dans le payload conservé dans une DB et qui peut-être remonté par l’outil de type SIEM.

Ces outils SIEM permettent aussi d’avoir des infos intéressantes pour le décideur (métriques sécurité, reporting) ou pour l’analyste. Ainsi on peut détecter certains phénomènes ou attaques plus facilement avec des représentations graphiques des évènements (les scans lents par exemple) d’autant plus s’ils sont corrélés.

A la base, je suis un gros sceptique des IDS. Ils sont contournables, remontent des faux-positifs et nécessitent des ressources pour les exploiter. Ces points sont très liés d’ailleurs à l’écriture, le tuning et la gestion des règles (à lire à ce sujet : erratasec.blogspot.com/20… ).

Cependant si au final on les place bien et qu’on les intègre avec d’autres évènements (logs serveurs, hids, etc …), ils constituent un outil intéressant et contribuant à la sécurité du système d’information. Comme tout produit de sécurité c’est un élément parmi d’autre, qu’il faut intégrer dans un process (c’est à dire ne pas les mettre n’importe où, sans tuner les règles, sans corrélé ni analyser ….).

My 0.02 € …

N’empêche que j’espère que Diamond Edition pourra me faire une *vraie* facture, car je me vois mal présenter une facture pour un t-shirt à 180€ à mon chef en expliquant tant bien que mal que c’est pour un Symposium Sécurité de renom…

Deux conclusions, s’habiller est plus facile lorsqu’on est etudiant, et les T-shirts SSTIC pesent 0 grammes.

(addendum) vive le cache de Firefox, j’ai retrouvé mon commentaire…

Il n’empêche que malgré la teneur de mon billet et mon avis sur la question, je vais bel et bien devoir en déployer, des IDéPéS un peu partout… Parce que comme tu le soulignes si justement, le RSSI se doit "de faire comme tout le monde" ne serait-ce que pour contenter sa direction qui lit la presse pipole informatique (non je ne pense pas à Hakin9… quand même !) et qui est persuadée que c’est nécessaire.

@sid: tu as raison. Tiens, ca me rappelle une discussion que j’ai eu avec un RSSI d’un grand groupe industriel samedi matin (on supervisait l’exam CISSP ensemble, je ne dirai rien de plus) qui s’interrogeait sur le risque de coupure des flux de production par les IPS, et plus précisément par l’idée d’un bypass en cas de crise… On en revient toujours au même point… Par ailleurs si toi ou l’un d’entre vous avez des idées de bons produits de corrélation, racontez-moi tout ça par email, je suis preneur

Bref, me voilà donc à la tête d’un projet IDPS/gestion des logs qui ne m’enchante guère… enfin si, mais il faut que je reste sur mes gardes !

Le problème de la détection d’intrusion n’est pas solutionnable avec des boîtes. Tant que les gens n’auront pas compris ça, ils n’y arriveront pas. La détection d’intrusion est un problème _global_ et non local, qui se règle surtout à grand coups d’agrégation et de corrélation, dont les sondes ne sont qu’une partie et non un tout. Tant que les gens n’auront pas compris ça, ils n’y arriveront pas.

Par exemple, à Eurosec 2005, nous avions fait un talk avec Phil* où nous avions, à travers cet exemple d’utilisation de Sebek2, l’importance de l’aggrégation de données pour la caractérisation des alertes et le forensic en cas d’incident. Parce qu’une alerte Snort, ce n’est rien de plus que "ce paquet a une sale gueule, c’est peut-être une attaque". Alors qu’en corrélant, on peut avoir des choses du genre :

* c’est peut-être une attaque à destination du serveur HTTP ;
* trois fils d’Apache ont crashé ;
* un quatrième vient de spawner un /bin/sh.

Comprendre "ça mon gars, c’est une alerte grave". Ou alors :

* c’est peut-être une attaque à destination du serveur HTTP ;
* le firewall a bloqué le flux.

Comprendre "c’était peut-être une attaque, mais globalement, on s’en fout".

C’est ça ma vision des IDS. Un bon système de reporting de logs bien géré.

Pour commenter le commentaire précédent, le truc qui m’amuse avec les détecteurs d’anomalies, c’est que les gens qui les entraînent oublient que la vie "normale" d’un réseau inclue aussi des évènements exceptionnels qui doivent être pris en compte. On pourrait citer la gestion de crise ou encore la réponse à incident. Et si on n’a pas pris ce facteur en compte, et si on en fait un IP, on va se retrouve dans une situation dans laquelle on a un énorme besoin de ressources mais… on se fait bloquer par l’IPS parce notre activité est considérée comme déviante. Si je me souviens bien, un .gov avait publié un papier là-dessus expliquant comment ils en avait fait l’expérience, la solution ayant été de couper tous le système de prévention d’intrusion du site pendant la période de crise. En fait, ils ne l’auraient jamais rallumé

* sid.rstack.org/pres/0503_…