Batman Day: el único superhéroe cuyo superpoder es la preparación

Hoy es Batman Day, que se celebra el tercer sábado de septiembre.

Y para mí, sin discusión posible: la mejor. La de 1989, con Michael Keaton bajo la capucha y Jack Nicholson de Joker. Peliculón. La Gotham de Tim Burton, la música de Danny Elfman, el Joker bailando con la música de Prince en un museo mientras destroza los cuadros.

Se ha discutido mil veces si Keaton era el Batman adecuado. Para mí lo era precisamente por lo que le criticaban: como Bruce Wayne parecía un tipo raro y algo apagado, no un galán. Y eso es lo correcto, porque el personaje interesante nunca fue el murciélago.

Aquí va por qué Batman es el único superhéroe del que se puede aprender algo profesional.

El trabajo de verdad está en el pretil: el kit abierto, el mapa marcado y la lista por tachar antes de que pase nada. Ilustración generada con IA para este artículo; no representa a Batman ni a ningún personaje de DC Comics.

El único cuyo superpoder es la preparación

Superman vuela. Flash corre. Batman tiene presupuesto, tiempo y la costumbre de hacer los deberes.

Y eso lo convierte, entre todos ellos, en el único que se parece a nuestro trabajo. Batman no resuelve por capacidad sobrehumana: resuelve porque ya había pensado en esto antes de que pasara. Es un perfil de operaciones con un patrimonio detrás.

Lo que me interesa es que su método se parece mucho al que recomendamos en seguridad y demasiadas organizaciones siguen sin aplicar:

1. Anticipa el escenario antes de que ocurra, en frío, sin la presión del incidente.
2. Prepara la respuesta y la deja disponible en el sitio donde hará falta.
3. Ensaya.
4. Y cuando pasa, ejecuta lo ensayado en lugar de improvisar.

Suena obvio escrito así. Ahora dime cuántas empresas que conozcas han ensayado alguna vez la restauración de una copia de seguridad. O han hecho el simulacro de «hoy no tenemos acceso al correo corporativo, ¿cómo nos coordinamos?».

Muchas no tienen un plan. Y algunas de las que lo tienen, lo tienen en un documento dentro del sistema que se va a caer, que es como guardar la llave de repuesto dentro de casa.

El cinturón: por qué siempre lleva lo que necesita

El chiste eterno sobre Batman es que en el cinturón lleva convenientemente el artefacto exacto para cada situación. En los años sesenta llegó al extremo del espray antitiburones, que sigue siendo el mejor ejemplo de exceso de preparación de la cultura popular.

Pero mirado de cerca, el cinturón es una idea buenísima y muy mal copiada: es un kit de respuesta a incidencias, limitado en tamaño y preparado de antemano.

Lo que hace que funcione no es que lleve todo. Es que lleva poco y sabe qué lleva. Un cinturón con doscientos compartimentos sería inútil en una pelea.

Traducido a nuestro oficio, un buen kit de incidencias tiene cinco o seis cosas y ni una más:

• Los accesos de emergencia, guardados fuera del sistema que pueden estar caídos.
• Los teléfonos de quien hay que avisar, incluido el proveedor de hosting y el responsable legal, en un sitio accesible sin la red corporativa.
• La copia de seguridad restaurable y, escrito al lado, cuánto tarda en restaurarse de verdad. Medido, no estimado.
• El procedimiento de despublicación, para poder dejar el servicio en mantenimiento en dos minutos sin pensar.
• Y una página de estado fuera de tu infraestructura, porque si se cae todo también se cae el sitio donde ibas a explicar que se ha caído todo.

Eso es un cinturón. Si tu plan de incidencias tiene cuarenta páginas, no tienes un cinturón: tienes un armario, y en un incidente nadie abre armarios.

Los planes contra su propio equipo

Y ahora la parte que de verdad quería contar, porque es la mejor lección de seguridad que ha dado un cómic.

En Torre de Babel, la historia que Mark Waid escribió para la Liga de la Justicia en el año 2000, se descubre que Batman ha elaborado planes de contingencia para neutralizar a cada uno de sus compañeros. Uno por uno. Sus amigos. Por si alguno fuera manipulado, sustituido o se volviera contra el resto.

Cuando se enteran, se sienten traicionados. Y desde el punto de vista humano tienen toda la razón.

Pero desde el punto de vista técnico Batman está haciendo lo correcto, y tiene nombre: modelado de amenazas. Consiste precisamente en preguntarse «¿qué pasa si el elemento en el que confío falla o actúa en mi contra?». No porque desconfíes de tus compañeros, sino porque la confianza no es un control de seguridad.

Es la misma pregunta que hay que hacerse con las cosas de las que tu sistema depende y que todo el mundo da por buenas:

• ¿Qué pasa si la librería que instalé con un comando cambia de manos y la nueva versión trae algo dentro?
• ¿Qué pasa si la cuenta de un empleado de confianza aparece publicada en una filtración?
• ¿Qué pasa si el proveedor al que le diste acceso a tu servidor es el que resulta comprometido?
• ¿Qué pasa si la clave de la API que lleva tres años en el mismo sitio ya la ha visto media docena de personas que ya no trabajan aquí?

De esa última escribí a partir de un incidente real con claves de API, y del proveedor comprometido va uno de los artículos de octubre. Es el mismo ejercicio: dar por hecho que algo de confianza va a fallar, y decidir antes qué harás entonces.

Y ahora el giro, que es lo importante

Porque la historia no acaba en «Batman tenía razón». Acaba en que Ra's al Ghul entra en sus archivos, le roba los planes y los ejecuta uno a uno contra la Liga. Cada compañero cae exactamente por donde Batman había escrito que caería.

Ese detalle convierte una buena anécdota en una lección de verdad: el documento donde has escrito cómo derribar tu propio sistema es, él mismo, un objetivo.

Lo digo porque lo veo constantemente en empresas que están haciendo las cosas bien y no se dan cuenta del efecto secundario:

• El informe de auditoría con la lista de vulnerabilidades pendientes, circulando por correo y en la carpeta compartida de todo el mundo.
• El diagrama de red completo, con nombres de máquinas y puertos, en la wiki interna abierta a los cien empleados.
• El documento de recuperación con las contraseñas de administrador «para tenerlas a mano».
• El repositorio de infraestructura, público en un descuido, con los nombres de los recursos y la estructura entera del entorno.

Hacer modelado de amenazas genera un artefacto que se convierte en un objetivo especialmente sensible, porque es el mapa. Y el mapa hay que tratarlo como lo que es: acceso restringido, cifrado, con registro de quién lo abre, y separando el diagnóstico de las credenciales, que nunca deben vivir en el mismo documento.

Batman hizo bien el ejercicio y mal la custodia. Es exactamente el error de las empresas que ya han superado la fase de no hacer nada.

Alfred

Alfred Pennyworth cose las heridas, mantiene la casa, gestiona los suministros, cubre las ausencias de Bruce y sostiene toda la operación. No sale en los carteles.

Todo equipo tiene su Alfred: la persona que mantiene lo que ya funciona. Y en muchos equipos esa persona está infravalorada en relación con su importancia real, por un motivo estructural: su trabajo se mide en cosas que no han pasado. Hay organizaciones donde eso se ve y se reconoce; son menos de las que deberían.

Nadie recibe un reconocimiento por el incidente que no ocurrió. El que apaga el fuego es un héroe visible; el que impidió el fuego es un gasto. De esto va, en el fondo, lo del mantenimiento.

Si tienes un Alfred, dile hoy que lo sabes. Cuesta cero y se van todos los años por lo contrario.

El Joker, y por qué no es exactamente ingeniería del caos

Nicholson, además de estar inmenso, interpreta un personaje que cumple una función muy concreta: introduce fallos impredecibles en un sistema que se creía estable.

Gotham funcionaba. Mal, corrupta, pero funcionaba. El Joker no ataca un punto débil conocido: hace cosas absurdas, sin patrón y sin objetivo económico, y así descubre todos los supuestos que la ciudad daba por hechos.

La comparación inmediata, en nuestro oficio, sería con la ingeniería del caos: provocar fallos en tu propio sistema, a propósito y de forma controlada, para descubrir las suposiciones que nadie escribió:

• Apagar una máquina a mitad de la mañana y ver si alguien se enteró.
• Cortarle la red a un servicio y comprobar si los demás degradan con elegancia o se caen en cadena.
• Llenar un disco al 100% y ver qué pasa. Siempre pasa algo, y nunca es lo que esperabas.
• Cambiar la hora del sistema y observar el desastre, que es la versión seria del chiste de la medianoche de Gremlins.

Pero el paralelismo, aunque bonito, no es exacto. Lo del Joker es caos a secas. La ingeniería del caos no consiste en meter fallos impredecibles a ver qué pasa, sino en montar experimentos controlados para aumentar la confianza en que el sistema aguanta. Eso implica lo que el Joker no tiene: una hipótesis escrita antes de tocar nada, unos límites —qué entorno, qué tráfico, qué horario—, observación mientras ocurre, una forma de abortar en cuanto se tuerza y un aprendizaje que se escribe al final.

Lo demás sí lo comparten: si el experimento lo eliges tú, es un martes por la mañana con todo el equipo delante; si lo elige el azar, es un sábado de madrugada. Y hay fallos que aparecerán tarde o temprano, aunque no todos ni de forma inevitable. Lo que decides no es si va a pasar, sino cuánto sabrás de tu sistema cuando pase.

Feliz Batman Day

Hoy, en honor al hombre que no tiene poderes y gana igual:

1. Haz el ejercicio incómodo: elige una cosa de la que dependas y en la que confíes ciegamente, y escribe qué harías si te fallara mañana.
2. Guarda ese documento como el mapa que es. Acceso restringido, y las credenciales nunca en el mismo sitio que el diagnóstico.
3. Monta el cinturón, no el armario. Cinco cosas, fuera de tu infraestructura, y con los tiempos de restauración medidos.
4. Y dale las gracias a tu Alfred, que lleva años impidiendo incidentes que nadie te ha contado.

(¿Keaton o los demás? Keaton. Y el que diga lo contrario, que me explique primero el baile de Nicholson en el museo.)