Resumo

  • Em novembro de 1988, software compartilhado, relações de confiança e conectividade passaram a transportar uma falha correlacionada; desconectar continha o risco local e, ao mesmo tempo, dificultava a chegada de avisos e correções.
  • O CERT Coordination Center surgiu como superfície informacional de resposta — recebimento, validação, mobilização de especialistas e contato com fornecedores — sem autoridade para dar ordens aos sites.
  • Seu legado é uma camada comum deliberadamente estreita: coordenação compartilhada, execução local e legitimidade obtida por credibilidade e contenção.

A conectividade como domínio comum de falha

Em 2 de novembro de 1988, o programa de Robert Tappan Morris começou a se replicar pela jovem Internet. O acórdão posterior descreveu quatro caminhos tentados: falhas no sendmail e no fingerd, relações de hosts confiáveis e adivinhação de senhas. O acontecimento foi histórico não por uma única porta, mas porque máquinas administradas separadamente compartilhavam software, confiança e alcance suficientes para falhar juntas.

O processo judicial registra que o programa deveria se espalhar discretamente sem interferir de forma material no uso normal. Para contornar uma resposta falsa de “já infectado”, ele insistia em uma de cada sete respostas afirmativas. Morris subestimou a frequência das consultas. Processos duplicados se acumularam até tornar sistemas lentos, inoperantes ou travados.

O episódio mostrou cedo o risco correlacionado da rede. Cada administrador ainda mandava em seu próprio sistema, mas todos precisavam redescobrir os mesmos fatos sob pressão. Autonomia formal, sem uma fonte comum de informação confiável, não produzia resposta rápida.

Isolar para proteger, isolar-se da solução

A ação defensiva mais direta foi a desconexão. O GAO registrou que muitos sites retiraram do ar quase todas as máquinas e mantiveram uma ou duas para comunicação e análise. Isso reduziu os caminhos do worm, mas também enfraqueceu o meio pelo qual a correção confiável precisava circular.

Morris e um contato em Harvard tentaram enviar anonimamente uma mensagem com uma solução, porém o congestionamento a atrasou. Pesquisadores de Berkeley identificaram os problemas de sendmail e fingerd e publicaram patches; até a noite de sexta-feira, a maioria dos sites havia eliminado o worm. Enquanto isso, telefones, fax e redes pessoais sustentaram a coordenação porque a própria Internet estava congestionada, parcialmente desconectada e sem uma entrada de emergência reconhecida por todos.

Também não há contagem definitiva. As famosas 6 mil máquinas não vieram de um censo oficial. O GAO rastreou o número a uma extrapolação e registrou outra estimativa de mil a 3 mil sistemas. Os valores de perdas eram igualmente incertos. A imprecisão revela a capacidade que faltava: não existia um mecanismo comum de recebimento capaz de montar rapidamente um quadro operacional verificável.

A falha institucional por trás do código

O worm explorou vulnerabilidades, mas a resposta revelou um vazio organizacional. Relatos posteriores descrevem análises duplicadas, orientações conflitantes, dúvida sobre quem deveria ser notificado e grande desigualdade de conhecimento. Grupos universitários realizaram boa parte da erradicação. Governo e fornecedores tinham outros recursos, porém nenhum mecanismo permanente os conectava na velocidade do incidente.

Não era necessário dar a um ator a operação de todas as máquinas. Faltava uma função mais limitada: receber relatos, comparar indícios, proteger divulgações sensíveis, convocar o especialista certo, trabalhar com fornecedores e publicar uma orientação que cada site pudesse avaliar.

Em meados de novembro, a DARPA estabeleceu o Computer Emergency Response Team no Software Engineering Institute da Carnegie Mellon University. Uma apresentação histórica posterior aponta 17 de novembro. O núcleo inicial tinha cinco pessoas, apoiadas por mais de cem especialistas de prontidão e relações com governo, empresas e grupos de usuários. Era uma central para competência distribuída, não uma tentativa de substituí-la.

Credibilidade no lugar de coerção

O GAO resumiu três objetivos iniciais: coordenar a resposta da comunidade, servir de ponto para vulnerabilidades e correções e promover trabalho preventivo. O mesmo documento foi explícito: o CERT não tinha autoridade; só podia recomendar. Para funcionar, seus conselhos teriam de conquistar credibilidade e apoio.

Seu controle incidia sobre o fluxo de informação: validar um relato, escolher o especialista ou fornecedor a contatar, organizar e distribuir uma solução. O centro não possuía os sistemas afetados nem podia obrigar universidade ou empresa a desconectar, corrigir ou reconectar. A execução continuava plural e local.

Credibilidade era capital operacional. Se o coordenador vazasse relatos, divulgasse patches duvidosos ou transformasse dependência temporária em pretensão de mando, perderia a cooperação voluntária necessária para enxergar o conjunto. Verificação cuidadosa e contenção reduziam o tempo entre a primeira observação e uma ação coletiva segura.

O direito respondia a outra pergunta

O processo de Morris examinou acesso não autorizado, dano e o alcance da Computer Fraud and Abuse Act; a corte de apelação confirmou a condenação. Essa camada tratava de responsabilidade. O CERT tratava de como operadores deveriam agir enquanto os fatos ainda eram incompletos e os sistemas continuavam em risco.

Uma sentença não autentica um patch de madrugada, conecta sozinha um engenheiro do fornecedor a um administrador universitário ou mantém um canal confidencial de notificação. Direito e operação podiam coexistir porque respondiam a problemas diferentes.

Uma central, não um trono

Criar um ponto focal não transferiu soberania sobre a Internet. O CERT não passou a ser dono de vulnerabilidades, fornecedores ou redes participantes. E a fundação de 1988 não prova que todos os centros posteriores conservaram os mesmos incentivos.

A conclusão precisa é que uma camada comum de informação pode ampliar a capacidade coletiva sem absorver a execução local. Ela permanece legítima quando o propósito é limitado, a evidência pode ser revisada e os participantes mantêm poder de decisão e saída.

Neutralidade, porém, é frágil. O coordenador vê relatos que ninguém vê isoladamente; sucessos concentram reputação; financiamento e dependência de fornecedores alteram incentivos. A afirmação fundadora de que o CERT não tinha autoridade deve ser lida como restrição arquitetônica. O Morris Worm não demonstrou a necessidade de um soberano da segurança. Demonstrou que operadores autônomos precisavam de uma central confiável — e que as decisões continuassem nas pontas.

Fontes e limites das evidências

A reconstrução usa o RFC 1135, o relatório do GAO de junho de 1989, o caso United States v. Morris, a análise técnica de Eugene Spafford, as histórias do SEI sobre gestão profissional de incidentes e os avisos CERT de 1988, a história técnica do SEI, o depoimento do GAO, a apresentação APRICOT sobre o início do CERT/CC e o contexto de ferramentas do RFC 1147. Não houve censo completo; números de infecção e perdas permanecem estimativas disputadas.