Deux pistes sérieuses pour le live forensique

Chose promise, chose due, voici enfin un article faisant la preuve de mon intérêt constant pour le live forensique.

Le RFC 3227 - Guidelines for Evidence Collection and Archiving recommandait, dès février 2002, que le premier élément de preuve à récolter dans le cadre d'une enquête forensique était la mémoire physique (la RAM) du système suspecté. Si le recueil de cette mémoire physique est peu à peu rentrée dans les procédures forensiques et de réponse aux incidents (IR), son analyse, quant à elle, reste problématique.

Lorsque j'ai quitté mon équipe IR voilà trois mois, cette analyse n'était réalisée qu'en cas de besoin impérieux de retrouver des mots de passe, adresses IP, adresses de messagerie ou URL, permettant de confondre un suspect contre lequel de fortes présomptions existaient. Pour cela, le binôme IR utilisait les outils strings et grep pour retrouver de tels éléments de preuve. L'analyse la plus "poussée" consistait alors en une exploration rapide sous bintext des mégaoctets de l'image de cette mémoire physique, afin de relever les chaînes de caractères ASCII pouvant avoir une quelconque utilité.

L'été 2005 avec son challenge forensique du DFRWS (Digital Forensic Research Workshop) a marqué une révolution pour les chercheurs INFOSEC de la planète qui se sont pris d'intérêt pour le live forensique. Sur le terrain, c'est en fait la tendance lourde des codes malveillants (virus et rootkits et autres malwares de dernière génération) à empêcher leur analyse statique via les techniques anti-forensiques qui ont amené les équipes IR et les enquêteurs forensiques à vouloir se doter d'outils puissants pour analyser efficacement cette mémoire physique, seule détentrice d'éléments non chiffrés (non-cryptés, pour utiliser un anglissisme) de ces malwares.

L'année 2006 a vu l'apparition publique des premiers outils d'analyse live fonrensique. Les uns bâtis sur l'accès à l'objet \Device\PhysicalMemory, les autres s'appuyant sur le contenu du fichier crash dump généré par les systèmes Windows après un BSoD (Blue Sreen of Death). Deux problèmes techniques sont actuellement à prendre en compte pour le choix d'une de ces familles d'outils :
- à partir de la sortie du service pack 1 de MS Windows 2003 (printemps 2005), l'objet \Device\PhysicalMemory n'est plus accessible à partir du mode utilisateur
- à l'exception de Windows 2003, les systèmes MS Windows génèrent par défaut un crash dump de taille insuffisante (il en est de même pour Windows Vista RC1)

Après avoir fait le tour de quelques outils, ma préférence va à la famille bâtie sur les crash Dump. Il est vrai qu'elle convient d'avantage à une équipe IR qui peut se permettre d'imposer de grandes images crash dump aux serveurs MS Windows sous sa responsabilité, plutôt qu'à un enquêteur forensique envoyé auprès d'un quelconque système suspect. Voir pour cela l'article de la base de connaissance Microsoft ici.

Afin d'affiner mon expérience en la matière, je pense à très court terme (dès la semaine prochaine) travailler sérieusement sur les deux pistes suivantes :
- l'outil Kernel Memory Space Analyzer de Microsoft
- une extraction à l'aide de l'outil LiveKD.exe et sa commande .dump /f fichier-dump.dmp à partir d'un système distant ou d'un système dont la fonction ou la fragilité le rendent impossible à crasher.

D'ici là, il me reste à préparer le TOEIC que je passe à la fin de cette semaine ! ;-)

Sur la perception

Ayant quitté mon équipe IR depuis plus de trois mois, je me prends à philosopher par manque de cas croustillants à me mettre sous la dent (une des raisons pour lesquelles je délaisse ce blog, sans aucun doute). La vieillesse me gagne peut-être ou serait-ce l'ennui ??

Devant rapidement trouver un nouveau job pour nourrir ma petite famille, j'ai dû réviser mes classiques INFOSEC, afin de ne pas sécher bêtement devant une question basique. En effet, après une vingtaine d'entretiens, je n'ai eu aucune question relative au live forensique ou à la réponse aux incidents ! Il faut dire que ces sujets semblent d'avantage faire partie de la recherche expérimentale que des bonnes pratiques ITIL ou autre standard à la mode... Toujours est-il qu'en révisant ces fameux classiques, j'ai eu soudain un doute vertigineux vis à vis des fondements même de l'INFOSEC tels qu'on me les a enseignés voilà plus de dix ans.

Lorsque j'étais encore étudiant en mathématiques appliquées (voila deux éternités...) j'ai subi la torture mentale infligée par un spécialiste de la logique formelle. Outre de violentes migraines, je me souviens essentiellement du théorème de Gödel, qui démontre l'assertion géniale suivante : "Au sein même d'un système, il est impossible de démontrer logiquement les points de départ."

Pour l'INFOSEC, cela peut signifier que les définitions de base (la sécurité, l'équation du risque, les menaces...) sont uniquement de simples perceptions et des valeurs arbitraires !

Or, lorsque l'on connait la part non négligeable qu'ont pris les spécialistes de l'assurance financière dans la genèse de l'actuelle doctrine INFOSEC, notamment dans la gestion des risques, il y a lieu de s'inquiéter. Pour s'en convaincre, il suffit de passer en revue les méthodologies d'analyse de risque à notre disposition. En France, EBIOS et Mehari sont des exemples flagrants de systèmes pseudo-scientifiques - si courants dans l'analyse financière - qui sont bâtis sur du vent et dont le résultat ne repose que sur l'expérience et le pragmatisme de celui qui les met en oeuvre. Ce qui requiert une compétence très poussée en programmation neuro-linguistique. ;-)

Je connais une bonne dizaine de définitions du concept de sécurité appliqué à l'INFOSEC. Cependant, celle que je préfère n'est préconisée ni par les instances de standardisation, ni par notre très haute autorité française : la DCSSI. Il s'agit tout bêtement d'une définition utilisée depuis une trentaine d'années dans le monde du renseignement qui, contrairement au monde de l'assurance financière, possède un encrage évident dans la réalité. Cette définition est la suivante :

La sécurité est le processus du maintien du risque perçu à un niveau acceptable.

Rien de bien nouveau me direz-vous, il fait simplement de l'esbroufe, sachant qu'il n'a plus grand chose à dire sur le sujet du live forensique. Peut-être, bien que je garde encore quelques cartes dans ma manche... Mais, il y a une notion qui peut paraître anodine au premier abord dans cette définition, mais qui change pourtant toute la donne. Il s'agit de la perception.

Pour un esprit français, baigné depuis sa plus tendre enfance dans la logique carthésienne, la dialectique et le raisonnement, la perception reste un élément secondaire de la réflexion. La pensée critique reste le nec plus ultra en Occident, et surtout dans notre beau pays. Il suffit pour cela d'écouter, même d'une oreille très discrète, les derniers discours de la présidentielle...

La perception est pourtant une clé, et même la clé, pour comprendre le concept de sécurité. Pour un analyste INFOSEC, la perception est la partie la plus importante de sa réflexion. En fait, toutes les erreurs que j'ai rencontrées avec mon équipe IR provenaient d'erreurs de perception, dues très souvent au stress, au manque de sommeil et surtout à une trop grande précipitation. En pratique, les erreurs de logique sont rares dans l'analyse INFOSEC. Malgré tout, nous avons appris en tant que fiers enfants de Descartes que réfléchir consiste uniquement à éviter les erreurs de logique.

Ainsi, si l'on s'attache à la perception du risque et non simplement au risque dans un système absolu, on peut alors se concentrer sur les menaces et non plus uniquement sur les vulnérabilités. Lorsque l'on observe les listes de diffusion INFOSEC que cela soit dans notre pays ou encore dans les pays anglosaxons, on voit que la majorité de notre attention est focalisée sur les vulnérabilités découvertes par les chercheurs INFOSEC.

Pour ne pas ajouter un troll à mon actif (et surtout pour ne pas blesser la susceptibilité d'un de mes uniques lecteurs), je tiens simplement à dire qu'il est vain de courir après toutes les vulnérabilités que l'on nous sert chaque semaine. Il faut en fait se concentrer sur les menaces qui nous concernent, comme le font les professionnels du renseignement depuis des années.

Mon expérience en la matière est que l'étude des groupes possédant la capacité et l'intention de nuire à une organisation est bien plus importante (et bien plus utile) que d'essayer de patcher toutes les vulnérabilités qui apparaissent. Il suffit pour s'en convaincre, de faire une pause en reconsidérant les dernières vulnérabilités zéro-days qui viennent d'être publiées à la veille de nombreuses mises à jour de produits de sécurité et des conférences INFOSEC printanières (Oups, j'ai encore trollé :-).

L'étude de tels groupes reste très confidentielle. J'ai relevé dernièrement un post assez proche de cette thématique ici. Si vous en connaissez d'autres, je suis preneur.