Groupe de travail Réseau |
D. Brezinski, In-Q-Tel |
Request for Comments : 3227 |
T. Killalea, neart.org |
BCP : 55 |
février 2002 |
Catégorie : Bonnes practiques actuelles |
Traduction Claude Brière de L'Isle |
Lignes directrices pour la collecte et l'archivage des preuves d'un événement de sécurité
Statut de ce mémoire
Le présent document spécifie les bonnes pratiques actuelles de l'Internet pour la communauté de l'Internet, et appelle à des discussions et suggestions pour son amélioration. La distribution du présent mémoire n'est soumise à aucune restriction.
Notice de copyright
Copyright (C) The Internet Society (2002). Tous droits réservés.
Résumé
Un "incident de sécurité" tel que défini dans le "Glossaire de la sécurité de l'Internet", RFC 2828, est un événement système relevant de la sécurité dans lequel la politique de sécurité du système est violée ou battue en brèche de quelque autre manière. L'objet du présent document est de fournir aux administrateurs de système des lignes directrices sur la collecte et l'archivage des preuves qui se rapportent à un tel incident de sécurité.
Si la collecte des preuves est faite correctement, elles sont beaucoup plus utiles pour appréhender l'attaquant, et elles on de bien meilleures chance d'être admissibles dans le cas d'engagement de poursuites.
Table des Matières
1.1 Conventions utilisées dans ce document
2. Principes directeurs durant la collecte des preuves
2.3 Considérations de confidentialité
8. Considérations pour la sécurité
Un "incident de sécurité" tel que défini dans la [RFC2828] est un événement système relevant de la sécurité dans lequel la politique de sécurité du système est violée ou battue en brèche de quelque autre manière. L'objet du présent document est de fournir aux administrateurs de système des lignes directrices sur la collecte et l'archivage des preuves qui se rapportent à un tel incident de sécurité. Notre intention n'est pas d'insister pour que tous les administrateurs de système suivent aveuglément ces lignes directrices chaque fois qu'ils ont un incident de sécurité. Nous voulons plutôt donner des indications sur ce qu'ils devraient faire si ils choisissent de collecter et protéger les informations qui se rapportent à une intrusion.
Une telle collecte représente un effort considérable de la part des administrateurs de système. De gros progrès ont été faits ces dernières années pour accélérer la réinstallation du système d'exploitation et pour faciliter la réinitialisation d'un système à un 'état connu', rendant donc 'l'option facile' encore plus attractive. Pendant ce temps là, peu a été fait pour faciliter l'archivage des preuves (l'option difficile). De plus, l'accroissement des capacités de disque et de mémoire et l'utilisation plus largement répandue de tactiques furtives et de dissimulation de traces par les attaquants ont exacerbé le problème.
Si la collecte des preuves est faite correctement, elles sont beaucoup plus utile pour l'appréhension de l'attaquant, et ont de bien meilleures chances d'être admissibles dans le cas de poursuites.
Ces lignes directrices devraient vous servir de base pour formuler les procédures de collecte des preuves de votre site, et vous devriez incorporer les procédures de votre site dans votre documentation sur le traitement des incidents. Les lignes directrices du présent document peuvent n'être pas appropriées dans toutes les juridictions. Une fois que vous avez formulé les procédures de collecte des preuves de votre site, vous devriez vous faire confirmer par votre conseil juridique qu'elles sont adéquates dans la juridiction dont vous relevez.
1.1 Conventions utilisées dans ce document
Les mots clés "EXIGE", "DOIT", "NE DOIT PAS", "DEVRAIT", "NE DEVRAIT PAS", et "PEUT" dans le présent document sont à interpréter comme décrit dans "Mots clés à utiliser dans les RFC pour indiquer les niveaux d'exigence" [RFC2119].
2. Principes directeurs durant la collecte des preuves
- Suivre la politique de sécurité de votre site et démarrer le traitement d'incident approprié et avertir les personnels juridiquement compétents.
- Saisir une image aussi précise du système que possible.
- Tenir des notes détaillées. Elles devraient comporter les dates et les heures. Si possible, générer une transcription automatique (par exemple, sur les systèmes Unix, le programme 'script' peut être utilisé, cependant le fichier de sortie qu'il génère ne devrait pas être le support de la preuve). Les notes et sorties d'imprimante devraient être signées et datées.
- Noter la différence entre l'horloge système et l'UTC. Pour chaque horodatage fourni, indiquer si l'heure utilisée est l'UTC ou l'heure locale.
- Soyez prêts à témoigner (peut-être des années plus tard) en expliquant toutes les actions entreprises et leur chronologie. Des notes précises seront vitales.
- Réduire les changements apportés aux données lors de leur collecte. Cela ne se limite pas aux changements de contenu ; vous devriez éviter de mettre à jour le fichier ou les heures d'accès au répertoire.
- Supprimer les possibilités de changement de l'extérieur.
- Si vous êtes confronté au choix entre collecte et analyse, vous devriez faire d'abord la collecte et ensuit l'analyse.
- Bien que ce ne soit pas la peine de le dire, vos procédures devraient pouvoir être mises en œuvre. Comme pour tous les aspects d'une politique de réponse aux incidents, les procédures devraient être testées pour s'assurer de la possibilité de leur mise en œuvre, en particulier en temps de crise. Si possible, les procédures devraient être automatisée pour des raisons de rapidité et de précision. Soyez méthodiques.
- Pour chaque appareil, une approche méthodique devrait être adoptée suivant les lignes directrices décrites dans votre procédure de collecte. La rapidité sera souvent un élément critique de sorte que là où il y a un grand nombre d'appareils qui doivent être examinés, il peut être approprié de répartir le travail entre une équipe pour collecter les preuves en parallèle. Cependant, sur un même système, la collecte devrait être faite pas à pas.
- Procéder du plus volatile au moins volatile (voir l'ordre de volatilité ci-dessous).
- Vous devriez faire une copie binaire du support du système. Si vous souhaitez faire une analyse argumentaire, vous devriez faire une copie binaire de votre copie preuve à cette fin, car votre analyse va presque certainement altérer les heures d'accès au fichier. Éviter de construire votre argumentation sur la copie preuve.
Lors de la collecte des preuves vous devriez procéder du plus volatile au moins volatile. Voici un exemple d'ordre de volatilité pour un système normal :
- registres, antémémoires
- tableaux d'acheminement, antémémoire arp, tableau de traitement, statistiques noyau, mémoire
- systèmes de fichiers temporaires
- disque
- connexion à distance et données de surveillance qui sont pertinentes pour le système en question
- configuration physique, topologie du réseau
- supports d'archive
Il est très facile de détruire des preuves, le plus souvent par inadvertance.
- Ne fermez pas le système tant que vous n'avez pas terminé la collecte des preuves. Beaucoup de preuves peuvent être perdues et l'attaquant peut avoir altéré les servies de scripts de démarrage/fermeture pour détruire les preuves.
- Ne faites pas confiance aux programmes du système. Faites fonctionner vos programmes de collecte de preuves à partir de supports bénéficiant d'une protection appropriée (voir ci-dessous).
- Ne faites pas fonctionner des programmes qui modifient l'heure d'accès de tous les fichiers du système (par exemple, 'tar' ou 'xcopy').
- Lorsque vous retirez des accès externes pour les changer, notez que déconnecter ou filtrer simplement du réseau peut déclencher des "commutateurs morts" qui détectent qu'ils sont hors du réseau et effacent les preuves.
2.3 Considérations de confidentialité
- Respecter les règles de confidentialité et les lignes directrices de votre société et de votre juridiction légale. En particulier, assurez vous qu'aucune des informations collectées avec les preuves que vous recherchez n'est rendue disponible à quiconque n'aurait pas normalement accès à ces informations. Cela inclut l'accès à des fichiers de connexion (qui peuvent révéler des schémas de comportement d'utilisateur) aussi bien que des fichiers de données personnelles.
- Ne faites pas intrusion dans le domaine privé des personnes sans de fortes justifications. En particulier, ne collectez pas d'informations dans des zones où vous n'avez normalement pas de raisons d'accéder (comme des mémoires de fichiers personnels) si vous n'avez pas d'indications suffisantes qu'il y a un incident réel.
- Assurez vous que vous avez le soutien des procédures établies par votre compagnie lorsque vous parcourez les étapes de la collecte des preuves d'un incident.
Les preuves informatiques doivent être
- Admissibles : Elles doivent être conformes à certaines règles légales pour pouvoir être présentées à une cour de justice
- Authentiques : Il doit être possible de lier positivement le matériel de preuve à l'incident.
- Complètes : Elles doivent raconter toute l'histoire et non pas seulement une perspective particulière.
- Fiables : Il ne doit rien y avoir sur la façon dont la preuve a été collectée et ensuite traitée qui laisse subsister un doute sur son authenticité et sa véracité.
- Crédibles : Elles doivent être directement crédibles et compréhensibles par un tribunal.
Vos procédures de collecte devraient être aussi détaillées que possible. Comme c'est le cas avec vos procédures globales de traitement d'incident, elles devraient être non ambiguës, et devraient minimiser la quantité de prises de décisions nécessaire durant le processus de collecte.
Les méthodes utilisées pour collecter des preuves devraient être transparentes et reproductibles. Vous devriez être prêt à reproduire précisément les méthodes que vous avez utilisé, et à faire tester ces méthodes par des experts indépendants.
- Où sont les preuves ? Faites la liste des systèmes qui ont été impliqués dans l'incident et à partir desquels les preuves seront collectées.
- Établir ce qui est vraisemblablement pertinent et admissible. Dans le doute, il vaut mieux collecter trop que trop peu.
- Pour chaque système, obtenir l'ordre de volatilité pertinent.
- Retirer les accès externes aux changements.
- Suivre l'ordre de volatilité, collecter les preuves avec les outils exposés à la Section 5.
- Enregistrer la mesure de la dérive de l'horloge système.
- Interrogez vous sur ce qui peut être d'autres preuves lorsque vous travaillez aux étapes de la collecte.
- Documenter chaque étape.
- Ne pas oublier les personnes impliquées. Prendre note de qui était là et de ce qu'ils faisaient, de ce qu'ils ont observé et de la façon dont ils ont réagi.
Lorsque c'est faisable, vous devriez envisager de générer des sommes de contrôle et des signatures cryptographiques des preuves collectées, car cela facilitera la préservation d'une forte chaîne de preuves. Ce faisant, vous ne devrez pas altérer les preuves.
Les preuves doivent être strictement sécurisées. De plus, la chaîne de garde de ces preuves doit être clairement documentée.
Vous devriez être capable de décrire clairement comment les preuves ont été trouvées, comment elles ont été traitées et tout ce qui leur est arrivé.
Ce qui suit doit être documenté :
- Où, quand et par qui les preuves ont été découvertes et collectées.
- Où, quand et par qui les preuves ont été traitées ou examinées.
- Qui a eu la garde des preuves, durant quelle période. Comment elles ont été mémorisées.
- Quand les preuves ont changé de gardien, quand et comment est survenu le transfert (y compris les numéros d'enregistrement, etc.).
Si possible, on devrait utiliser pour l'archivage des supports couramment utilisés (plutôt que quelque obscur support de stockage).
L'accès aux preuves devrait être extrêmement restrictif, et devrait être clairement documenté. Il devrait être possible de détecter un accès non autorisé.
Vous devriez avoir les programmes dont vous avez besoin pour la collecte des preuves et de l'argumentation sur un support en lecture seule (par exemple, un CD). Vous devriez avoir préparé un tel ensemble d'outils pour chaque système d'exploitation que vous gérez avant d'avoir à l'utiliser.
Votre ensemble d'outils devrait comporter ce qui suit :
- un programme pour examiner les processus (par exemple, 'ps').
- des programmes pour examiner l'état des systèmes (par exemple, 'showrev', 'ifconfig', 'netstat', 'arp').
- un programme pour faire des copies binaires (par exemple, 'dd', 'SafeBack').
- des programmes pour générer des sommes de contrôle et des signatures (par exemple, 'sha1sum', un 'dd' capable de faire des sommes de contrôle, 'SafeBack', 'pgp').
- des programmes pour générer des images du cœur de système et les examiner (par exemple, 'gcore', 'gdb').
- des scripts pour la collecte automatique des preuves (par exemple, la boîte à outils de l'autopsie [FAR1999]).
Les programmes de votre boîte à outils devraient être reliés de façon statique, et ne devraient pas exiger l'utilisation de bibliothèques autres que celles du support en lecture seule. Même alors, dans la mesure où les outils racine modernes peuvent être installés à travers des modules noyau téléchargeables, vous devriez envisager que vos outils pourraient ne pas vous donner une peinture complète du système.
Vous devriez être prêt à témoigner de l'authenticité et de la fiabilité de vos outils.
[FAR1999] Farmer, D., and W Venema, "Computer Forensics Analysis Class Handouts", http://www.fish.com/forensics/
[RFC2119] S. Bradner, "Mots clés à utiliser dans les RFC pour indiquer les niveaux d'exigence", BCP 14, mars 1997.
[RFC2196] B. Fraser, "Manuel de la sécurité des sites", septembre 1997, (FYI0008) (Information).
[RFC2350] N. Brownlee, E. Guttman, "Attentes pour la réponse à un incident de sécurité informatique", juin 1998. (BCP0021)
[RFC2828] R. Shirey, "Glossaire de la sécurité sur l'Internet", FYI 36, mai 2000. (Obsolète, remplacée par la RFC 4949.)
Tous nos remerciements pour les commentaires constructifs reçus de Harald Alvestrand, Byron Collie, Barbara Y. Fraser, Gordon Lennox, Andrew Rees, Steve Romig et Floyd Short.
8. Considérations pour la sécurité
Tout ce document est consacré aux problèmes de sécurité.
Dominique Brezinski |
Tom Killalea |
In-Q-Tel |
Lisi/n na Bro/n |
1000 Wilson Blvd., Ste. 2900 |
Be/al A/tha na Muice |
Arlington, VA 22209 |
Co. Mhaigh Eo |
USA |
IRELAND |
|
téléphone : +1 206 266-2196 |
mél : dbrezinski@In-Q-Tel.org |
mél : tomk@neart.org |
Copyright (C) The Internet Society (2002). Tous droits réservés.
Le présent document et ses traductions peuvent être copiés et fournis aux tiers, et les travaux dérivés qui les commentent ou les expliquent ou aident à leur mise en œuvre peuvent être préparés, copiés, publiés et distribués, en tout ou partie, sans restriction d’aucune sorte, pourvu que la déclaration de copyright ci-dessus et le présent et paragraphe soient inclus dans toutes telles copies et travaux dérivés. Cependant, le présent document lui-même ne peut être modifié d’aucune façon, en particulier en retirant la notice de copyright ou les références à la Internet Society ou aux autres organisations Internet, excepté autant qu’il est nécessaire pour le besoin du développement des normes Internet, auquel cas les procédures de copyright définies dans les procédures des normes Internet doivent être suivies, ou pour les besoins de la traduction dans d’autres langues que l’anglais. Les permissions limitées accordées ci-dessus sont perpétuelles et ne seront pas révoquées par la Internet Society ou successeurs ou ayant droits.
Le présent document et les informations y contenues sont fournies sur une base "EN L’ÉTAT" et LE CONTRIBUTEUR, L’ORGANISATION QU’IL OU ELLE REPRÉSENTE OU QUI LE/LA FINANCE (S’IL EN EST), LA INTERNET SOCIETY ET LA INTERNET ENGINEERING TASK FORCE DÉCLINENT TOUTES GARANTIES, EXPRIMÉES OU IMPLICITES, Y COMPRIS MAIS NON LIMITÉES À TOUTE GARANTIE QUE L’UTILISATION DES INFORMATIONS CI-ENCLOSES NE VIOLENT AUCUN DROIT OU AUCUNE GARANTIE IMPLICITE DE COMMERCIALISATION OU D’APTITUDE À UN OBJET PARTICULIER.
Remerciement
Le financement de la fonction d’édition des RFC est actuellement fourni par l’Internet Society.