Résumé

  • En novembre 1988, le ver a transformé logiciels communs, relations de confiance et connectivité en risque corrélé ; la déconnexion protégeait chaque site tout en freinant l’arrivée des alertes et des correctifs.
  • Le CERT Coordination Center a répondu par une surface de coordination informationnelle — réception, vérification, mobilisation d’experts et liaison avec les fournisseurs — sans disposer du pouvoir d’ordonner.
  • Sa portée historique tient à cette limite : une couche commune peut être décisive dans un réseau distribué si sa légitimité repose sur la compétence, la confiance et la retenue.

Une panne commune sans opérateur commun

Le 2 novembre 1988, le programme de Robert Tappan Morris a commencé à se reproduire sur le jeune Internet. L’arrêt de la cour d’appel décrit quatre voies tentées : des failles de sendmail et de fingerd, les relations entre hôtes de confiance et la recherche de mots de passe. Le caractère historique de l’incident ne réside pourtant pas dans une seule faille. Des machines administrées séparément partageaient assez de logiciels, de confiance et de portée réseau pour former un même domaine de défaillance.

Selon le dossier judiciaire, le programme devait se propager discrètement sans entraver sensiblement l’usage normal. Pour contourner une fausse réponse indiquant qu’une machine était déjà infectée, il recommençait une fois sur sept. Morris avait sous-estimé la fréquence des requêtes. Les copies se sont accumulées jusqu’à ralentir, bloquer ou rendre des systèmes inutilisables. L’effet opérationnel a dépassé le périmètre prévu.

La connectivité avait changé la nature de l’autonomie. Chaque responsable conservait la maîtrise de ses machines, mais chacun devait reconstruire les mêmes faits dans l’urgence. Une autorité locale intacte ne suffisait pas à produire une réponse collective rapide.

Se couper pour survivre, se couper du remède

Le geste défensif le plus immédiat fut l’isolement. Le GAO rapporte que de nombreux sites ont déconnecté la plupart de leurs machines et n’en ont gardé qu’une ou deux pour communiquer et analyser. La surface d’exposition diminuait, mais le canal nécessaire à la diffusion d’informations fiables se dégradait lui aussi.

Morris et un contact à Harvard ont tenté d’envoyer anonymement un message de remède ; la congestion l’a retardé. À Berkeley, des chercheurs ont identifié les problèmes de sendmail et de fingerd et publié des correctifs. Le vendredi soir, le ver avait disparu de la plupart des sites. Entre-temps, téléphone, télécopie et réseaux personnels avaient porté une partie essentielle de la coordination : l’Internet était congestionné, fragmenté et dépourvu d’une porte d’urgence reconnue par tous.

Même l’ampleur reste incertaine. Le chiffre célèbre de 6 000 machines n’est pas un recensement officiel. Le GAO l’a rattaché à une extrapolation et a aussi consigné une estimation de 1 000 à 3 000 systèmes. Les montants de pertes reposaient sur des bases tout aussi fragiles. Cette imprécision révèle une capacité absente : aucun dispositif commun ne pouvait agréger assez vite les observations pour construire une situation défendable.

Le diagnostic institutionnel de l’après-coup

Le code a permis la propagation ; la réponse a révélé les lacunes d’organisation. Les récits de l’époque font état d’analyses répétées, d’informations de réparation contradictoires, d’une incertitude sur le destinataire des signalements et de compétences très inégales. Les équipes universitaires d’informatique ont joué un rôle majeur dans l’éradication. Les agences et les fournisseurs détenaient d’autres ressources, sans mécanisme permanent pour les connecter à la vitesse de l’incident.

Le besoin n’était pas de remettre toutes les machines à un seul acteur. Il était plus précis : recevoir les signalements, comparer les indices, protéger les divulgations sensibles, trouver le bon spécialiste, travailler avec les fournisseurs et diffuser des recommandations que chaque site pouvait juger.

À la mi-novembre, la DARPA a établi le Computer Emergency Response Team au Software Engineering Institute de Carnegie Mellon University. Une présentation historique ultérieure retient la date du 17 novembre. Le noyau comptait cinq personnes, épaulées par plus de cent spécialistes joignables et par des liens avec l’administration, l’industrie et les utilisateurs. Il s’agissait d’un standard pour compétences distribuées, non d’un substitut à celles-ci.

La crédibilité comme capital d’exploitation

Le GAO résumait trois missions initiales : coordonner la réaction de la communauté, servir de point pour les vulnérabilités et les corrections, et favoriser le travail préventif. Il précisait aussi que CERT n’avait aucune autorité et ne pouvait que recommander. Son influence dépendrait de sa crédibilité et du soutien de la communauté.

CERT agissait donc sur les flux d’information : validation d’un signalement, contact d’un fournisseur, mobilisation d’un expert, formulation d’un avis. Il ne possédait pas les systèmes concernés et ne pouvait obliger ni université ni entreprise à se déconnecter, corriger ou revenir en ligne. L’exécution restait locale et plurielle.

Dans ce modèle, la confiance n’était pas un supplément moral. Un coordinateur qui divulguait les rapports, relayait des correctifs douteux ou transformait une dépendance temporaire en prétention au commandement perdait la coopération volontaire dont dépendait sa visibilité. La vérification et la retenue réduisaient au contraire le délai entre la première observation et une action sûre de la communauté.

Le droit répondait à une autre question

La procédure contre Morris a déterminé comment l’accès non autorisé et ses effets relevaient du Computer Fraud and Abuse Act ; la cour d’appel a confirmé la condamnation. Cette réponse fixait responsabilité et limites juridiques. CERT devait résoudre un problème différent : comment agir pendant que les faits restent incomplets et que les systèmes sont encore menacés.

Un tribunal peut attribuer la responsabilité après enquête. Son jugement ne vérifie pas un correctif au milieu de la nuit, ne met pas spontanément en relation ingénieur et administrateur, et ne crée pas un canal confidentiel de signalement. La couche juridique et la couche opérationnelle se complétaient parce qu’aucune ne cherchait à devenir l’autre.

Un standard, pas un trône

Le succès d’un point focal n’a transféré aucune souveraineté sur l’Internet. CERT n’est devenu propriétaire ni des vulnérabilités, ni des fournisseurs, ni des réseaux participants. L’histoire de 1988 ne garantit pas davantage que tous les organismes ultérieurs aient conservé les mêmes limites.

Elle démontre une proposition plus rigoureuse : dans l’urgence, une couche informationnelle commune peut accroître fortement la capacité collective sans absorber l’exécution locale. Sa légitimité tient à un objet limité, à des preuves contrôlables et à la faculté des participants de décider ou de quitter le dispositif.

Cette neutralité peut se perdre. Le coordinateur voit des rapports que nul participant ne voit seul ; le succès concentre la réputation ; financement et dépendance industrielle modifient les incitations. La mention explicite d’une absence d’autorité doit être lue comme une contrainte d’architecture. Le ver Morris n’a pas montré qu’il fallait un souverain de la sécurité. Il a montré que des compétences isolées avaient besoin d’un standard commun — dont chaque correspondant restait libre.

Sources et limites des preuves

Cette analyse s’appuie sur le RFC 1135, le rapport du GAO de juin 1989, l’arrêt United States v. Morris, l’analyse technique d’Eugene Spafford, les histoires du SEI sur la gestion professionnelle des incidents et les avis CERT de 1988, l’histoire technique du SEI, le témoignage du GAO, la présentation APRICOT sur les débuts de CERT/CC et le contexte d’outillage du RFC 1147. Aucun recensement complet n’existe ; infections et pertes restent des estimations contestées.