Troisième Workshop TRANSITS

Les 30 et 31 octobre 2003, le Cert-IST a participé au troisième Workshop TRANSITS, sponsorisé par TERENA. TRANSITS (http://www.ist-transits.org/) est un projet financé par la communauté européenne au même titre que le projet EISPP auquel le Cert-IST participe depuis juin 2002. Ce "TRANSITS Workshop" s'est déroulée au sud de Milan avec une vingtaine de participants.

Les participants à ce Workshop étaient des personnes appartenant ou non à des CERT : en majorité provenant d'universités et académiques, et provenant de pays aussi variés que Chypre, la Norvège, l'Estonie ou l'Iran.


Le Workshop est décomposé en 5 parties.

1. Vulnérabilités et avis (Andrew Cormack - Janet-CERT)

Cette présentation commence en expliquant d'où viennent les vulnérabilités : c'est en somme une loi de la Nature et même si les programmeurs savent écrire du code propre (sans débordement de pile) depuis longtemps, il en existe pourtant toujours. Andrew Cormack enchaîne ensuite sur les différentes sources d'information (rapports d'incident, communauté de divulgation, hackers, vendeurs, etc...) et explique que malheureusement, l'information idéale (fiable, rapide, précise, adaptée) n'existe pas. Enfin, il analyse les tâches qui incombent à un CERT (CSIRT) pour traiter cette information : distribution, interprétation, investigation et coordination.

Cette présentation reprend les points clé de l'activité CERT, comme par exemple le fait qu’un CERT se doit d’aider ses lecteurs (clients, membres) et ne doit pas les effrayer avec ses avis, ou encore que l'investigation autour d'une vulnérabilité prend du temps, mais que ce temps est nécessaire.

2. Considérations techniques (Klaus Möller - DFN-CERT)

Cette présentation analyse le déroulement d'une intrusion : collecte d'information, accès non autorisé au système, dissimulation des traces et utilisation abusive des ressources du système. Suit une présentation du profil des attaquants (hackers, crackers, script kiddies). Klaus Möller explique que beaucoup d'attaquants sont motivés par les "IRC wars". Les différentes méthodes de collecte d'information sont ensuite analysées (scans, ping, portscans, scans TCP et UDP, information récupérée dans la bannière de connexion, etc...).

Klaus Möller analyse ensuite deux types de vulnérabilités : les débordements de pile et les vulnérabilités de type "Format String". La partie dissimulation des traces (sur Unix et Windows) a été en particulier abordée. Enfin, Klaus Möller explique à quoi sert une intrusion pour un attaquant (stockage de données, site Warez, DoS, etc...).

3. Considérations légales (Jacques Schuurman - Surf Net)

Cette présentation moins formelle présente les aspects légaux de l'activité d'un CERT. En réalité, ce terrain est en évolution constante, les lois concernant l'informatique n'existent pas toujours, peuvent se contredire mutuellement et varient d'un pays à l'autre (or Internet et donc les incidents de sécurité sont transfrontaliers). Jacques Schuurman insiste sur le fait que nous ne sommes pas des avocats et que le cas échéant, il vaut mieux recourir aux services d'une personne compétente en la matière. Des questions se posent notamment en terme de juridiction (où le "crime" a t’il été commis? Sur la machine de l'attaquant, le proxy, le serveur ou la machine de la victime), et en terme de responsabilité. Jacques Schuurman indique qu'un CERT est régulièrement confronté à des problèmes légaux (fraudes, "cop yright", contenus illégaux, données confidentielles, etc...). Et même si ce domaine est vaste et changeant, un CERT se doit de connaître les règles/lois en vigueur dans son pays.

4. Considérations organisationnelles (Don Stikvoort - Stelvio)

Cette présentation donne des éléments concernant les aspects organisationnels pour un CERT. Tout d'abord, comment positionner un CERT dans une organisation, en tenant compte de deux points fondamentaux : l'autorité et l'"escalade" (si quelque chose va mal, l'incident doit pourvoir être remonté à qui de droit). Nombre de participants ont des soucis à ce niveau (problème de reconnaissance). Don Stikvoort insiste sur le fait qu'un CERT doit avoir un "feed-back" de sa communauté (mailing-lists, séminaires, etc...). En fait, les motivations lors de la création d'un CERT sont différentes : universitaires, commerciaux et gouvernementaux, et chaque CERT est un cas particulier (il n'y a pas de standard). Don Stikvoort donne ensuite des recommandations concernant les moyens (des locaux à la mise en place d'un garde-barrière propre au CERT), la constitution de l'équipe ( différentes compétences sont nécessaires), les liens qu'un CERT se doit d'établir (FIRST, TF-CSIRT, etc...), et la pérennité du CERT (surtout pour les CERT commerciaux).

5. Considérations opérationnelles (David Parker - Uniras)

Cette présentation est la suite logique de la précédente, et approfondit les "rouages" permettant à un CERT de fonctionner. En résumé, un CERT c'est : un service (ou plutôt des services, le plus important étant le traitement d'incident), une équipe (avec des locaux dédiés), des moyens de communication dédiés, des systèmes, et des procédures. David Parker explique qu'il faut bien définir le service fourni : horaires, astreintes, "hot-line" (téléphonique, e-mail)... La constitution de l'équipe est aussi très importante et des compétences variées sont nécessaires, pas toujours à temps plein (aspects légaux, contact avec la presse, etc...). D'autres points tout aussi importants sont également abordés : établissement de contacts (FIRST, éditeurs, etc...), accès distant pour les membres de l'équipe, site web (public/privé), modèles de rapport d'incident (IODEF par exemple), publicité (un CERT doit être connu). Enfin, la dernière partie de cette présentation est consacrée au traitement d'incident : avant l'incident (travail proactif afin de réduire les risques), réponse à un incident, après l'incident (tirer les leçons de l'incident).

La prochaine formation TRANSITS aura lieu à Hambourg les 25 et 26 mai 2004.