Resumen

  • El gusano de noviembre de 1988 convirtió software compartido, relaciones de confianza y conectividad en un fallo correlacionado; desconectar protegía cada sitio, pero también frenaba avisos y soluciones.
  • El CERT Coordination Center creó una superficie común de información —recepción, verificación, expertos, proveedores y recomendaciones— sin autoridad para ordenar a los operadores.
  • La lección duradera es una institución deliberadamente delgada: la coordinación puede ser común mientras la decisión y la ejecución siguen siendo locales.

Una red conectada, un riesgo compartido

El 2 de noviembre de 1988, el programa escrito por Robert Tappan Morris comenzó a replicarse por el joven Internet. La sentencia de apelación identificó cuatro vías que intentaba utilizar: fallos en sendmail y fingerd, relaciones entre anfitriones de confianza y adivinación de contraseñas. La magnitud histórica no procedió de una sola puerta, sino de que sistemas administrados por separado compartían suficiente software, confianza y alcance como para fallar juntos.

Según el expediente judicial, el programa debía propagarse sin llamar la atención ni interferir de forma apreciable en el uso normal. Para vencer una respuesta falsa de “ya infectado”, insistía en uno de cada siete casos afirmativos. Morris calculó mal la frecuencia de las consultas. Los procesos duplicados se acumularon hasta ralentizar, bloquear o dejar inservibles numerosas máquinas.

La conectividad transformó un error en riesgo correlacionado. Cada administrador conservaba el control formal de su sistema, pero todos tenían que reconstruir los mismos hechos bajo presión. La autonomía sin una fuente común de información verificable resultó demasiado lenta.

La defensa que cortó el camino de la cura

La medida más clara era aislarse. El GAO documentó que muchos sitios desconectaron casi todas sus máquinas y mantuvieron una o dos para comunicación y análisis. Se reducía la exposición al gusano, pero también se degradaba el canal por el que debían llegar los avisos y parches fiables.

Morris y un contacto de Harvard intentaron difundir anónimamente un remedio, pero la congestión retrasó el mensaje. Investigadores de Berkeley identificaron los problemas de sendmail y fingerd y publicaron parches; para el viernes por la noche el gusano había sido eliminado en la mayoría de los sitios. Entretanto, teléfonos, faxes y contactos personales sostuvieron la coordinación porque la red estaba congestionada, parcialmente fragmentada y sin una puerta de emergencia aceptada por todos.

Ni siquiera existe un recuento definitivo. Las conocidas 6.000 máquinas no proceden de un censo oficial. El GAO rastreó esa cifra hasta una extrapolación y registró además otra estimación de entre 1.000 y 3.000. Los cálculos de pérdidas fueron igual de inciertos. La falta de cifras sólidas no es un detalle: muestra que no existía una recepción común capaz de convertir observaciones dispersas en una imagen operativa defendible.

El fallo institucional detrás del fallo técnico

El código abrió las puertas, pero la respuesta reveló otra carencia. Los relatos posteriores hablan de trabajo duplicado, información contradictoria sobre reparaciones, dudas sobre a quién avisar y enormes diferencias de capacidad técnica. Grupos universitarios hicieron buena parte del trabajo práctico de erradicación. Gobierno y proveedores poseían recursos complementarios, pero no había un mecanismo permanente que los conectara a la velocidad del incidente.

No hacía falta entregar todas las máquinas a un único actor. Faltaba una función más estrecha: recibir informes, contrastarlos, proteger revelaciones sensibles, movilizar al especialista adecuado, coordinar al proveedor y publicar una recomendación que cada sitio pudiera evaluar.

A mediados de noviembre, DARPA estableció el Computer Emergency Response Team en el Software Engineering Institute de Carnegie Mellon University. Una presentación histórica posterior sitúa su creación el 17 de noviembre. El núcleo inicial era de cinco personas, apoyadas por más de cien especialistas localizables y relaciones con administración, empresas y usuarios. Era una centralita para competencia distribuida, no una sustitución de esa competencia.

La autoridad que dependía de no mandar

El GAO resumió tres propósitos: coordinar la respuesta comunitaria, servir de punto para vulnerabilidades y correcciones, y fomentar el trabajo preventivo. También fue explícito: CERT no tenía autoridad y solo podía recomendar. Sus consejos funcionarían si conseguía credibilidad y apoyo de la comunidad.

Su superficie de control era informativa. Podía decidir cómo validar un aviso, qué experto o proveedor contactar y cómo distribuir una solución. No era dueño de los sistemas afectados ni podía obligar a una universidad o empresa a desconectarse, parchear o volver a conectarse. La ejecución seguía siendo plural.

Por eso la credibilidad era capital operativo. Si el coordinador filtraba informes confidenciales, propagaba soluciones dudosas o convertía una dependencia temporal en pretensión de mando, perdía la cooperación voluntaria que le permitía ver el conjunto. Verificar con cuidado y actuar con contención reducía, en cambio, el tiempo entre la primera observación y una acción colectiva segura.

El derecho operaba en otra capa

El procesamiento de Morris respondió a cómo encajaban el acceso no autorizado y el daño en la Computer Fraud and Abuse Act. El tribunal de apelación confirmó la condena. CERT respondía a otra pregunta: cómo deben cooperar los operadores mientras los hechos son incompletos y el riesgo continúa.

Un tribunal puede atribuir responsabilidad después de reunir pruebas. Una sentencia no autentica por sí sola un parche de madrugada, no conecta a un ingeniero de producto con un administrador universitario y no mantiene un canal confidencial de notificación. Derecho y coordinación operativa podían coexistir porque ninguno necesitaba fingir ser el otro.

Centralita, no trono

Crear un punto focal no transfirió soberanía sobre Internet. CERT no pasó a poseer vulnerabilidades, proveedores ni redes participantes. Tampoco puede suponerse que todos los equipos de respuesta posteriores conservaran el mismo límite.

La conclusión histórica es más precisa: una capa común de información puede aumentar la capacidad colectiva sin absorber la ejecución local. Su legitimidad perdura cuando el propósito es limitado, las pruebas se pueden revisar y los participantes conservan decisión y salida.

La neutralidad, sin embargo, es frágil. El coordinador ve informes que ningún participante ve por separado; los éxitos concentran reputación; la financiación y la dependencia de proveedores cambian incentivos. La afirmación original de que CERT carecía de autoridad debe leerse como una restricción arquitectónica. El gusano Morris no probó que Internet necesitara un soberano de seguridad. Probó que sus operadores independientes necesitaban una centralita fiable.

Fuentes y límites de la evidencia

La reconstrucción utiliza RFC 1135, el informe del GAO de junio de 1989, United States v. Morris, el análisis técnico de Eugene Spafford, los materiales del SEI sobre gestión profesional de incidentes y los avisos CERT de 1988, la historia técnica del SEI, el testimonio del GAO, la historia de APRICOT sobre el comienzo de CERT/CC y el contexto de herramientas de RFC 1147. No hubo censo completo; las cifras de infección y pérdidas son estimaciones discutidas.