Salió hace unos días en Ars Technica una nota titulada «Drop database: what not to do after losing an IT job» que cuenta — una vez más — una historia que se repite con una regularidad que ya empieza a ser preocupante: un empleado de TI, después de perder su trabajo, ejecuta acciones destructivas contra la infraestructura de su (ex) empleador. En este caso, según el título de la nota, el clásico DROP DATABASE.
No tengo acceso al artículo original (Ars Technica me está bloqueado desde acá), pero el patrón lo conozco bien porque vengo viendo casos similares hace años. Desde mi punto de vista, vale la pena pararse a pensar el tema más allá del clickbait del título.
El patrón que se repite
Los casos suelen tener estos ingredientes:
- Un profesional de IT con accesos administrativos a sistemas productivos.
- Una desvinculación percibida como injusta o mal comunicada.
- Un proceso de offboarding que no revoca credenciales en el momento de la notificación.
- Acceso remoto o VPN que sigue funcionando 24-72 horas después.
- Una decisión emocional, casi siempre tomada en las primeras horas post-despido.
Y el final es siempre el mismo: una causa penal por computer fraud, cárcel efectiva o probation, una multa que arruina financieramente al protagonista, y una empresa que tarda meses en recuperarse.
La parte que casi nadie discute
Desde mi punto de vista, en estos casos hay dos errores que conviven y se potencian. El primero es del lado humano: cualquier ingeniero senior sabe que ejecutar un DROP DATABASE en producción es, además de un delito, una decisión que te define el resto de tu vida profesional. La industria es chica, las referencias circulan, y nadie te va a contratar después.
El segundo es del lado de la organización. Y este me importa más, porque es el que se puede prevenir. Las preguntas que toda empresa debería poder responder con un “sí” claro son:
- ¿La revocación de credenciales se hace en el momento de la notificación de despido, no “al día siguiente”?
- ¿Existe un proceso documentado de offboarding técnico, con checklist y dueño asignado?
- ¿Las cuentas de servicio y secretos que ese empleado conocía rotan automáticamente?
- ¿Los logs de las acciones administrativas de las últimas 24/48 horas se revisan?
- ¿Hay break-glass accounts separadas para que recuperar el control no dependa de la persona que se fue?
Lo que enseña este tipo de caso
Cada vez que aparece una de estas noticias me acuerdo de algo que dice un colega en seguridad: “el riesgo más alto de tu empresa no es el atacante externo, es el administrador que ya no quiere estar”. No porque la mayoría de los empleados sean potenciales sabotadores — la mayoría no lo son — sino porque una sola excepción te puede costar la operación entera.
La buena noticia es que no hace falta inventar nada nuevo: las prácticas de offboarding técnico están escritas hace 20 años y son baratas. La mala noticia es que la mayoría de las empresas las tiene mal documentadas o mal ejecutadas, porque “esto no nos va a pasar a nosotros”.
Fuente
El artículo original, para los que tengan acceso: Drop database: what not to do after losing an IT job (Ars Technica).
El offboarding técnico no es un detalle
Cada caso de estos que sale en los medios es una oportunidad para auditar nuestros propios procesos. Si dirigís un equipo o sos responsable de seguridad, vale la pena mirar el checklist de offboarding esta semana. No por miedo — por profesionalismo.
