Cuando acuñé el término «pandemia digital» el año pasado, estaba describiendo algo más que un fallo técnico: señalaba una nueva categoría de riesgo sistémico en la que un único punto de fallo puede desencadenar un efecto dominó que paraliza sectores enteros y erosiona la confianza.
La reciente interrupción global vinculada a Amazon Web Services (no es la primera y no será la última) nos ha recordado lo frágiles que pueden ser los ecosistemas digitales y que la resiliencia es una capacidad estratégica que debe practicarse y medirse con la misma disciplina con la que se audita un balance.
En este sentido, el entorno interconectado en el que operamos ha impulsado la innovación, pero también ha creado dependencias opacas. En demasiadas organizaciones, esas dependencias (proveedores cloud, integradores, herramientas de productividad, plataformas de pago o de identidad) se presuponen como commodities estables cuando, en realidad, constituyen la primera línea de riesgo operativo. El resultado es conocido: interrupciones que escalan en cuestión de segundos desde un servicio invisible hasta la caja registradora, el call center… o toda la cadena de suministro.
AWS ha identificado la causa raíz de la caída en un subsistema subyacente que monitoriza la salud de sus network load balancers. Esto refleja la inmensa mayoría de las realidades modernas, ya que un componente de una red enorme de ecosistemas digitales puede provocar interrupciones masivas en varias industrias de múltiples países. Las señales de pandemias digitales que nos golpearán en un futuro cercano son visibles y, si hoy la causa raíz es un fallo en un sistema, mañana puede ser un ciberataque masivo que arme esas vulnerabilidades (en un sentido amplio) y se convierta en la causa raíz.
La resiliencia, decisión de diseño
La resiliencia es, por encima de todo, una decisión de diseño. Y ese diseño comienza con un análisis de impacto en el negocio que no sea una lista de verificación anual, sino un mapa vivo de procesos, activos, datos y dependencias internas y externas, junto con métricas muy concretas: RTO (recovery time objective), RPO (recovery point objective) y MBCO (minimum business continuity objective). Los contratos, las arquitecturas y los procedimientos deben fluir a partir de ese mapa, y no al revés.
A continuación, toca elegir las palancas para romper el punto único de fallo. A nivel de infraestructura, el multirregión ya no es opcional para las cargas críticas; y para funciones esenciales, el multicloud debe estar basado en pruebas reales. Los desarrolladores de software en toda la cadena de suministro, con la ayuda de la inteligencia artificial, deberían empezar a construir sistemas más resilientes que aprovechen las lecciones aprendidas de incidentes anteriores.
En segundo lugar, la resiliencia operativa basada en ejercicios debe entrenarse. Los tabletops son útiles para alinear el liderazgo y afinar las comunicaciones, pero deben complementarse con game days y pruebas de caos controlado en preproducción para validar tolerancias, failover y procedimientos de degradación. Del mismo modo que un equipo de emergencias no improvisa el día del incendio, un comité de crisis no puede improvisar el día de la caída del servicio.
En tercer lugar, está la ciberresiliencia integrada en la cadena de suministro. El ransomware ha demostrado que el perímetro ya no existe (y que el proveedor más pequeño puede convertirse en la puerta más grande). Las evaluaciones de terceros, la segmentación de accesos y los planes de continuidad compartidos con proveedores críticos son ahora inseparables de la continuidad del negocio. Si un proveedor estratégico no puede demostrar su propio RTO/RPO, tu continuidad está en riesgo.
Pero antes de todo eso, debemos mirar seriamente la brecha global de competencias, que se amplía con la proliferación de tecnologías emergentes y vuelve obsoleto el conocimiento de la fuerza laboral no en cuestión de meses, sino de semanas. Todo empieza con una formación holística (especialmente en ciberseguridad y assurance), ya que será esta fuerza laboral la que diseñe e implemente el camino a seguir.
El factor humano
He insistido a menudo en que todos (no solo los profesionales de TI) debemos entender cómo funciona la inteligencia artificial, cómo se propaga el riesgo digital y qué decisiones humanas sostienen la resiliencia. Porque el factor humano es el primer vector de resiliencia: un empleado que sabe operar en modo degradado, que reconoce un incidente y que entiende su rol en el plan gana minutos inestimables cuando la automatización se detiene y la presión aumenta.
Por tanto, la formación debe ir más allá de «cómo evitar el phishing«. Debemos establecer priorización, criterios de degradación elegante de procesos, comunicación con clientes, proveedores y reguladores y revisiones posteriores a la acción para aprender de cada incidente. Aquí, los marcos de certificación profesional y las comunidades globales de profesionales que mantienen actualizada a la fuerza laboral aportan un valor distintivo: proporcionan un lenguaje común y verificable sobre riesgos, controles y continuidad, elevan el listón técnico y ético y hacen visibles las competencias que realmente importan el día del incidente.
Las grandes interrupciones demuestran que la resiliencia va más allá de cada empresa y toca el interés público. De ahí la necesidad de marcos regulatorios que se extiendan más allá de la infraestructura crítica, que eleven el listón de forma transversal, fomenten la ciberresiliencia en empresas y administraciones públicas y armonicen las obligaciones para proveedores críticos en todos los sectores clave de una economía.
Por último, es sensato aceptar que no podremos prevenir todos los incidentes (ni debemos perseguir la ilusión de la invulnerabilidad), pero sí podemos construir una cultura de aprendizaje de cada uno de ellos y actuar para proteger nuestros ecosistemas digitales de cara al siguiente.
Las pandemias digitales ya están aquí. Su duración e impacto pueden ser significativos, pero tolerables hoy… Mañana puede que no sea así.
