Veinte Días de Cortesía: El Despido que se Convirtió en el Primer Caso Federal de Sabotaje Informático de EE.UU.

Hace un par de años, revisando el protocolo de seguridad de una planta industrial, le pregunté al gerente de sistemas cuánto tardaban en desactivar el acceso de un administrador de red el día que dejaba la empresa. Se encogió de hombros. "Un par de días, cuando IT tiene tiempo," me dijo, como si hablara de renovar una licencia de software. Anoté la respuesta y no dije nada más en ese momento, pero pensé de inmediato en Tim Lloyd.

La sorpresa: el sabotaje casi nunca entra por la puerta de un extraño

Cuando una empresa piensa en sabotaje o en un ataque informático, casi siempre imagina a alguien de afuera: un desconocido tecleando en la oscuridad, en algún lugar remoto, buscando una grieta en el sistema. Por eso se invierte tanto en firewalls, en antivirus, en contraseñas más largas. Todo eso protege contra el extraño.

El problema es que la persona con más poder para destruir una operación entera casi nunca necesita romper nada. Ya tiene la llave. La tiene porque la empresa se la dio, porque confía en ella, porque durante años esa persona fue quien mantuvo los sistemas funcionando. El riesgo más grande no vive fuera del edificio. Vive en el organigrama, con su credencial vigente, hasta el último minuto que alguien se acuerde de quitársela.

El giro: veinte días de plazo, un servidor completo borrado en segundos

Tim Lloyd llevaba once años trabajando como administrador de sistemas en Omega Engineering, un fabricante de instrumentos de medición de precisión en Bridgeport, Nueva Jersey. Conocía cada rincón de la red de la empresa porque él mismo la había construido. El 10 de julio de 1996, después de meses de fricción con sus superiores, lo despidieron.

Nadie revisó ese mismo día qué accesos conservaba. Nadie auditó qué había quedado guardado en el servidor central que él mismo administraba. Veinte días después, el 31 de julio de 1996, la primera persona que inició sesión en ese servidor activó, sin saberlo, seis líneas de código que Lloyd había dejado programadas antes de irse. En el tiempo que tarda un servidor en encender, el código borró de manera permanente todos los programas de manufactura de la empresa: los diseños de producto, los controladores de las máquinas, los archivos que le decían a cada equipo de la planta qué fabricar y cómo. También purgó las cintas de respaldo que se guardaban en ese mismo servidor.

Omega Engineering, una empresa que en ese momento facturaba más de 50 millones de dólares al año, se quedó de un día para otro sin capacidad de manufactura. La reconstrucción de los programas costó cerca de 2 millones de dólares. La pérdida de ingresos y contratos sumó otros 10 millones. Ochenta empleados fueron despedidos porque, sencillamente, no había nada que producir. El costo total superó los 12 millones de dólares, según determinó el jurado años después.

Piénsalo un momento: nadie forzó una puerta, nadie hackeó una contraseña ajena, no hubo virus enviado desde el otro lado del planeta. Todo el daño lo hizo una persona usando accesos que la propia empresa nunca le retiró a tiempo. El caso se convirtió en la primera condena federal por sabotaje informático en la historia de Estados Unidos, y los investigadores solo pudieron probarlo porque encontraron fragmentos del código eliminado en una cinta de respaldo que, por descuido, había quedado en la propia estación de trabajo de Lloyd.

La lección práctica: la seguridad física y la continuidad no pueden vivir en oficinas separadas

Lo que el caso de Omega Engineering expone no es una falla de programación. Es una falla de coordinación entre áreas que, en la mayoría de las empresas, casi nunca se hablan entre sí: seguridad física, recursos humanos, tecnología y continuidad de negocio.

El primer paso, y el más barato, es sincronizar el reloj del despido con el reloj del acceso. Ningún empleado con privilegios sobre sistemas críticos debería conservar sus credenciales, su tarjeta de acceso o su sesión activa más allá del momento exacto en que recursos humanos comunica la salida. No un día después. No "cuando IT tenga tiempo".

El segundo paso es eliminar la figura del administrador único con poder total. Si una sola persona puede crear, modificar y borrar tanto los programas de producción como sus respaldos, esa persona no tiene un privilegio: tiene un interruptor de apagado de toda la empresa. Separar quién programa, quién respalda y quién autoriza cambios críticos no es burocracia innecesaria. Es la diferencia entre un incidente contenible y una parálisis total.

El tercer paso es prestar a las salidas conflictivas el mismo cuidado que a las contrataciones. Las empresas invierten mucho en verificar antecedentes antes de contratar y casi nada en gestionar con cuidado a alguien que se va enojado, sobre todo si esa persona tiene llaves digitales sobre procesos críticos. Un protocolo de salida con participación de seguridad física, además de recursos humanos, debería activarse automáticamente en cualquier desvinculación con fricción.

El cuarto paso es guardar los respaldos fuera del alcance de quien los genera. Si las copias de seguridad viven en el mismo servidor, en la misma red o bajo el control de la misma persona que administra el sistema principal, no son un respaldo real. Son una copia que puede desaparecer exactamente al mismo tiempo que el original.

El cierre

Volví a esa planta unos meses después de la auditoría. Le pregunté al mismo gerente si habían cambiado el protocolo de salida. Me dijo que sí, que ahora el acceso se desactiva en el sistema antes de que la persona salga de la sala donde le comunican la desvinculación, no después. Le conté brevemente la historia de Tim Lloyd y las veinte líneas de código que tardaron veinte días en detonar. Se quedó callado un momento y después dijo algo que no he olvidado: "Entonces el problema nunca fue la tecnología. Fue que nadie cerró la puerta a tiempo." Tenía razón. La cerradura más cara del mundo no sirve de nada si alguien se queda con una llave que nadie se acordó de pedirle de vuelta.