lundi 17 mars 2014

Il est temps de faire une pause et de réfléchir...

Chers amis et lecteurs,

Vous aurez remarqué que la fréquence - et je ne parle pas de l'intérêt - de mes publications a dramatiquement diminué. Or, je n'aime pas cette situation transitoire consistant à laisser ce blog dans un état végétatif.

C'est pourquoi j'ai pris la décision d'annoncer une longue pause dans mes productions sur ce blog et probablement également sur l'Alliance Géostratégique.

Plusieurs raisons expliquent cela mais je crois que, parmi elles, 3 d'entre elles sont les plus importantes.

La première est la sensation que le domaine de la lutte informatique ou de la sécurité a atteint une forme de seuil. Lorsque je débutais ce blog, l'idée de l'importance de ces problématiques n'était pas unanimement partagée de même que le niveau de sensibilisation ou de connaissance.

Aujourd'hui, avec des évolutions profondes de part le monde ainsi que plusieurs "cas" ou "affaires" retentissantes, personne ne doute de l'ampleur du travail à fournir et de la sensibilité de ces questions. Mais j'ai pourtant l'impression de "relire" un peu toujours les mêmes vieilles recettes ou idées.

Cette notion de travail est importante car j'ai toujours soutenu qu'il était nécessaire à un moment donné d'être praticien de ces questions pour les évoquer avec précisions et surtout, pouvoir critiquer tel ou tel point. 

Or, la sensation de seuil et l'idée du travail constitue ma deuxième raison. Il est temps, pour moi, de pratiquer plus intensément, d'innover, d'essayer, d'échouer, de recommencer afin de nourrir ma réflexion. Il sera alors temps, éventuellement, de continuer à écrire et de vous proposer mes deux ou trois idées sur ces sujets.

Enfin, cette volonté de s'ancrer professionnellement se fait nécessairement au détriment de la publication et de la tenue d'un blog. L'investissement professionnel et l'acquisition ou le cumul d'expériences riches n'est pas toujours compatible avec une attitude de recul plus réfléchie.

Ces raisons m'amènent donc à mettre en pause indéterminée ce blog. Il ne sera pas fermé et le contenu restera accessible. Peut-être y relaierais-je de temps à autre des informations sur tel ou tel événement. Je ne compte cependant pas forcément "déplacer" mon activité sur twitter ou autre bien que le suivi des fils restent intéressants.

Je vous remercie donc tous d'avoir pris le temps de me lire et parfois de me critiquer, féliciter ou encourager.

Source : 

à vous de voir :)

mardi 12 novembre 2013

Au revoir Cédric et merci pour tout !

Comme beaucoup le savent déjà, Cédric "Sid" Blancher nous a quitté lors d'un accident de parachutisme. 

C'était un garçon formidable et c'est une grande perte. J'ai eu l'occasion de le rencontrer, comme beaucoup, par nos blogs ou dans des colloques et conférences.Parler ainsi de lui n'est pas si facile et j'ai donc choisi de partager avec vous un bon souvenir avec lui qui illustre ses qualités. 

Il y a un mois environ, lors d'un déjeuner, Cédric était invité ainsi que d'autres convives. Parmi les autres invités, des blogueurs mais surtout, pour certain, sans lien aucun avec la SSI, la sécurité informatique ou encore le hacking.

J'ai dû partir dans les premiers, laissant les autres convives entre les mains de "Sid" tous en plein échange, discutant, riant...Et ça ne vous étonnera pas mais tous m'ont dit avoir passé un excellent moment et avoir rencontré quelqu'un d'une qualité rare. Et ce sont ces mêmes personnes qui m'ont averti ce week-end de la triste nouvelle et m'ont fait part de leur émotion.

De Cédric, je retiendrais ce moment : une rencontre suffisait pour être charmé, une rencontre et vous aviez un nouvel ami.

Mes pensées vont à sa famille et ses proches.

Quelques billets lui rendant hommage :






vendredi 27 septembre 2013

Réagir à l'attaque informatique : quelle complexité ?

Source : carnal0wnage.attackresearch.com
L'inspiration de cet article est venu ailleurs alors que l'on m'interrogeait sur la signification du terme "APT" pour "Advanced Persistant Threat" et sa portée. L'acronyme, un peu comme "cyber", a fini par devenir un terme usuel dont le sens n'est pas très clair. On entend parfois n'importe quoi à son sujet comme l'individu qui s'exclame : "ah, j'ai reçu un pdf ...j'ai une APT"...

En premier lieu, il ne s'agit pas d'une maladie mais d'une tentative de synthèse pour un phénomène complexe. L'idée est de représenter les caractéristiques des attaques informatiques "modernes" en insistant sur leurs facettes :

- "Avancées" comme relativement complexes parfois dans leurs aspects techniques, fréquemment dans l'orchestration des actions et la malignité des techniques. On peut également y entendre la prise de contrôle "avancée" d'un réseau avec le gain de privilèges très élevés.

- "Persistantes" car bien souvent, il s'agit, une fois entrée, de durer et de persister en dépit des efforts des responsables légitimes pour vous déloger. La notion de persistance illustre aussi bien gagner le contrôle durablement et en profondeur d'une machine que de l'ensemble d'un réseau.

Pour ma part, c'est ainsi que je le comprends. Effectivement, bien souvent, et comme le rappelle les éléments publics de certaines affaires célèbres, "Bercy" ou "Areva", tout cela commence bien souvent par un acte individuel et anonyme qu'est l'ouverture d'un fichier délibérément piégé et rendu attractif.

Toutefois, pour le profane, le praticien SSI apparaît parfois un peu austère voire légèrement autiste. En bref, il n'est pas illogique de ne pas comprendre ce qu'il en est. En revanche, il est toujours intéressant de savoir quels en sont les enjeux et les solutions trouvées.

Il existe de nombreux soucis dans la gestion de telles attaques. Aujourd'hui, nous en retiendrons principalement un : la détection. Nous pourrons évoquer plus tard, l'assainissement ou la reconstruction ou encore l'amélioration post-incident.

La détection recouvre en réalité deux actions bien distinctes. La première serait l'alerte, c'est à dire la découverte d'une infection initiale ou encore le sentiment que "ça colle plus" ou que "Houston, on a un problème"...La seconde consiste à mesurer le profondeur du problème et à détecter l'ampleur de celui-ci.

L'alerte dépend de nombreux facteurs. Une bonne équipe SSI peut disposer de moyens de recueil d'infos et d'analyse permettant de matérialiser de tels problèmes. Avec de la chance, l'outil de l'attaque pourra faire réagir un ou plusieurs des outils de sécurité que vous pourriez avoir (proxy, IDS, firewall, antivirus). 

Par exemple, si le composant malveillant contacte une adresse connue à l'extérieur, celle-ci peut être repérée grâce à l'usage de liste noire dans un proxy. Ou encore si le motif des flux est repérable, il pourra être détecté par une sonde de détection d'intrusion. Parfois, c'est le comportement de vos équipements qui sera détecté par un autre acteur : "Allo, M. RSSI ? Oui... ? Je suis administrateur sécurité dans la société machin et l'un de vos serveurs est décidément très motivé pour scanner mes ports et trouver des failles !".

Mesurer l'ampleur de l'attaque dépend de plusieurs facteurs. Mais l'idée principale est les acteurs en présence ne disposent pas toujours d'une représentation des systèmes à l'état "sain". Autrement dit, c'est un peu chercher la fameuse aiguille dans la non moins fameuse botte de foin ! Prenons un exemple courant : vous rencontrez un homme très pâle : est-il malade ? est-il doté d'une telle constitution ? A-t-il mangé quelque chose de périmé ? Ou bien ressort-il d'une longue maladie ?

C'est un peu la même idée en fait car la comparaison avec un état sain nécessite de d'abord connaitre cet état : la préparation, et c'est évident, à subir de telles attaques est donc indispensable. Par exemple, lorsque l'analyse détient la liste des comptes dans un annuaire d'entreprise ou encore la liste des utilisateurs d'un serveur, comment pourra-t-il savoir si certains comptes sont illégitimes ? 

Ou bien encore, tel programme est-il légitime ? Tel exécutable est-il bien celui qu'il parait être ?

Les professionnels de la SSI ont bien fini par comprendre le problème car l'alerte et la détection de l'ampleur ont un point commun : il faut savoir ce que l'on cherche. Une des réponses a donc été les indicateurs de compromission (IoC) qui se traduit bien en anglais : Indicators of Compromise.

L'objectif est de fournir tant un moyen d'alertes que de mesure de l'ampleur en définissant, par référence à un cas connu, les modalités ou les "symptômes" de l'infection. Le rapport Mandiant et la société du même nom ont d'ailleurs développé un outil comprenant un format (un langage commun) permettant de lire et de créer de tels indicateurs.

Dans l'exemple cité en source, il est possible de télécharger la liste des IOCs de l'attaque en question et de les parcourir afin de définir des modalités adaptées de recherche de ces caractéristiques. Notez aussi l'outil Yara qui a plusieurs  modules dont l'objet est d'intégrer plusieurs types d'IOC (des séquences de caractères par exemple) pour les recherchez de manière systématique sur des fichiers et des arborescences. On peut même y ajouter des règles en demandant de rechercher telle règle OU telle autre ou bien celle-ci ET celle-là.

L'originalité et l'utilité des IOC est la multiplicité des informations et la combinaison de celles-ci que l'on peut faire. Par exemple, dans le cas cité ci-dessous, on trouve aussi bien : des empreintes de fichiers, des adresses IP en destination (utilisées peut-être pour l'exfiltration de données ou l'envoi de commandes) ou encore des chaines de caractères spécifiques. 

Celles-ci sont combinées pour tenir compte des versions et évolutions du malware. C'est typiquement l'usage du "OU" : la diversité des empreintes uniques (hash) de fichiers ne limite par la possibilité de détecter telle ou telle version.

Les IOCs ne sont pas la solution parfaite mais adossées à la réactivité de la communauté, elles constituent une réponse intéressante à ces problématiques d'APT que nous venons d'évoquer. Nul doute que d'autres idées viendront afin de progresser dans le traitement de ces sujets complexe mais au coeur de l'actualité en sécurité !

Source :