Un petit texte d'ambiance, pour nous changer de la technique pure...
Bien que le combat en milieu urbain l'ai mis au rencard au profit du trinôme, mon opinion est que le binôme constitue la structure de base la plus efficace pour une équipe IR :
- un opérateur IR aux manettes : interlocuteur unique de l'administrateur distant en première ligne (souvent, le premier intervenant sur l'incident)
- un opérateur IR : tenant le cahier de bord et veillant au respect de la procédure
Ce binôme IR est composé, de préférence, du grand classique Mentor/Scarabé. Cette configuration permet d'éviter les éternels conflits de générations (ou de diviser pour régner selon les points de vue) et surtout de former en un rien de temps les nouveaux venus.
Voila pour la mise en situation...
L'objectif de toute investigation IR sur un évènement suspect consiste à déterminer si un incident sécurité informatique est survenu et - dans l'affirmative - comment il s'est produit. Un binôme d'opérateurs IR a cinquante minutes pour bâtir une hypothèse plausible et dix minutes pour la présenter au coordinateur de l'équipe IR. Ce dernier devra alors l'expliquer, en termes non-techniques, au responsable du système suspect (cas classique) ou au responsable de la cellule conduite (crise ou incident majeur).
Cinquante minutes peuvent être terriblement courtes, surtout avec un administrateur qui en passe quinze à trouver les clés de la baie technique... Le meilleur allié de l'équipe IR reste un simple cédérom d'investigation. Ce dernier peut contenir la distribution HELIX ou une petite compilation d'outils maison. Il doit bien sûr être détenu par l'administrateur du système suspecté ; sinon, nous avons encore perdu de précieuses minutes pour monter une autre manip' ! (vive la planification)
La quasi-majorité des systèmes d'extrémité actuels (serveurs et stations de travail) possèdent un lecteur de cédérom ou compatible. Ce qui n'est d'ailleurs plus le cas du lecteur de disquette. Parce qu'un cédérom ne peut pas être réécrit une fois gravé, il est théoriquement invulnérable à la corruption des codes malveillants (certains diront que les drivers ne le sont pas...).
Il reste au binôme IR à récupérer les données collectées : le réseau - via ce vieux netcat ou son petit frère cryptcat - reste le meilleur moyen, mais d'autres options doivent être planifiées.
Un fois le dispositif en place, le binôme IR doit s'assurer de collecter ou faire collecter assez d'informations pour déterminer si l'évènement rapporté est un incident sécurité informatique (et non une simple panne ou un bogue logiciel). Il doit collecter autant d'informations volatiles que possible sur le système suspect, en s'efforçant de ne pas piétiner l'éventuelle scène du crime. Le choix des outils d'investigation est alors primordial.
En comptant une moyenne de vingt minutes pour les préparatifs et un minimum de vingt minutes pour l'analyse, cela laisse moins de dix minutes pour réaliser la collecte ! Selon les informations déjà à disposition, l'OS et surtout la fonction du système suspecté, plusieurs options techniques s'offrent au binôme IR (de la plus lente à la plus rapide) :
- dialogue interactif avec l'administrateur qui exécute un certain nombre d'outils de recueil dont les résultats sont analysés à la volée par le binôme IR (choix préféré des opérateurs confirmés)
- récupération de la totalité de la mémoire physique du système
- lancement d'un script de recueil regroupant le résultat de plusieurs outils de collecte
Outre le temps qui reste au binôme pour fournir son diagnostique, l'autre facteur à prendre en compte est le principe d'échange d'Edmond Locard Ce principe fondateur des sciences forensiques stipule (de mémoire) : "lorsque deux objets viennent en contact, un transfert matériel a lieu entre eux." Ce principe peut également s'appliquer au monde numérique : "Lorsqu'un système se connecte à un autre via le réseau, il s'opère un échange d'informations entre eux".
Les rootkits et les intrus expérimentés s'évertuent toujours à effacer ce type d'informations. L'expérience d'un intrus tient d'ailleurs d'avantage à cet effacement qu'au choix de la méthode d'intrusion utilisée (on voit toujours les mêmes choses, mais ceci est une autre histoire...). Quant aux rootkits noyau, il faut développer pour chacun d'entre eux une méthode de détection spécifique, bien que je pense tester bientôt les outils de Joanna Rutkowska.
L'objectif de la collecte consiste à recueillir ce qui reste de ces informations à l'aide d'un large panel d'outils. Dans ce domaine, si un simple netstat est comparable à la vérification du registre d'un hôtel borgne, l'analyse de la mémoire physique peut, quant à elle, être comparée à l'analyse ADN de l'ensemble des fragments organiques trouvés sur la scène du crime.
Et voila, je suis revenu à la technique pure...
Bien que le combat en milieu urbain l'ai mis au rencard au profit du trinôme, mon opinion est que le binôme constitue la structure de base la plus efficace pour une équipe IR :
- un opérateur IR aux manettes : interlocuteur unique de l'administrateur distant en première ligne (souvent, le premier intervenant sur l'incident)
- un opérateur IR : tenant le cahier de bord et veillant au respect de la procédure
Ce binôme IR est composé, de préférence, du grand classique Mentor/Scarabé. Cette configuration permet d'éviter les éternels conflits de générations (ou de diviser pour régner selon les points de vue) et surtout de former en un rien de temps les nouveaux venus.
Voila pour la mise en situation...
L'objectif de toute investigation IR sur un évènement suspect consiste à déterminer si un incident sécurité informatique est survenu et - dans l'affirmative - comment il s'est produit. Un binôme d'opérateurs IR a cinquante minutes pour bâtir une hypothèse plausible et dix minutes pour la présenter au coordinateur de l'équipe IR. Ce dernier devra alors l'expliquer, en termes non-techniques, au responsable du système suspect (cas classique) ou au responsable de la cellule conduite (crise ou incident majeur).
Cinquante minutes peuvent être terriblement courtes, surtout avec un administrateur qui en passe quinze à trouver les clés de la baie technique... Le meilleur allié de l'équipe IR reste un simple cédérom d'investigation. Ce dernier peut contenir la distribution HELIX ou une petite compilation d'outils maison. Il doit bien sûr être détenu par l'administrateur du système suspecté ; sinon, nous avons encore perdu de précieuses minutes pour monter une autre manip' ! (vive la planification)
La quasi-majorité des systèmes d'extrémité actuels (serveurs et stations de travail) possèdent un lecteur de cédérom ou compatible. Ce qui n'est d'ailleurs plus le cas du lecteur de disquette. Parce qu'un cédérom ne peut pas être réécrit une fois gravé, il est théoriquement invulnérable à la corruption des codes malveillants (certains diront que les drivers ne le sont pas...).
Il reste au binôme IR à récupérer les données collectées : le réseau - via ce vieux netcat ou son petit frère cryptcat - reste le meilleur moyen, mais d'autres options doivent être planifiées.
Un fois le dispositif en place, le binôme IR doit s'assurer de collecter ou faire collecter assez d'informations pour déterminer si l'évènement rapporté est un incident sécurité informatique (et non une simple panne ou un bogue logiciel). Il doit collecter autant d'informations volatiles que possible sur le système suspect, en s'efforçant de ne pas piétiner l'éventuelle scène du crime. Le choix des outils d'investigation est alors primordial.
En comptant une moyenne de vingt minutes pour les préparatifs et un minimum de vingt minutes pour l'analyse, cela laisse moins de dix minutes pour réaliser la collecte ! Selon les informations déjà à disposition, l'OS et surtout la fonction du système suspecté, plusieurs options techniques s'offrent au binôme IR (de la plus lente à la plus rapide) :
- dialogue interactif avec l'administrateur qui exécute un certain nombre d'outils de recueil dont les résultats sont analysés à la volée par le binôme IR (choix préféré des opérateurs confirmés)
- récupération de la totalité de la mémoire physique du système
- lancement d'un script de recueil regroupant le résultat de plusieurs outils de collecte
Outre le temps qui reste au binôme pour fournir son diagnostique, l'autre facteur à prendre en compte est le principe d'échange d'Edmond Locard Ce principe fondateur des sciences forensiques stipule (de mémoire) : "lorsque deux objets viennent en contact, un transfert matériel a lieu entre eux." Ce principe peut également s'appliquer au monde numérique : "Lorsqu'un système se connecte à un autre via le réseau, il s'opère un échange d'informations entre eux".
Les rootkits et les intrus expérimentés s'évertuent toujours à effacer ce type d'informations. L'expérience d'un intrus tient d'ailleurs d'avantage à cet effacement qu'au choix de la méthode d'intrusion utilisée (on voit toujours les mêmes choses, mais ceci est une autre histoire...). Quant aux rootkits noyau, il faut développer pour chacun d'entre eux une méthode de détection spécifique, bien que je pense tester bientôt les outils de Joanna Rutkowska.
L'objectif de la collecte consiste à recueillir ce qui reste de ces informations à l'aide d'un large panel d'outils. Dans ce domaine, si un simple netstat est comparable à la vérification du registre d'un hôtel borgne, l'analyse de la mémoire physique peut, quant à elle, être comparée à l'analyse ADN de l'ensemble des fragments organiques trouvés sur la scène du crime.
Et voila, je suis revenu à la technique pure...
Articles
Aucun commentaire:
Enregistrer un commentaire