Resumen
- NotPetya entró en Maersk a través de un software utilizado para la declaración de impuestos en Ucrania e hizo que las aplicaciones y los datos no estuvieran disponibles en un entorno globalmente conectado. La empresa apagó sistemas adicionales como precaución, mientras que el robo de credenciales del malware y sus múltiples métodos de propagación hicieron que la aplicación de parches por sí sola fuera una defensa incompleta.
- Maersk mantuvo el control de sus buques, pero sus negocios de contenedores sufrieron una interrupción significativa. Las funciones de reservas, puertas de terminales e información de carga fallaron; APM Terminals informó que los servicios de puerta aún se estaban expandiendo en varios puertos tres días después del ataque. Los activos físicos permanecieron presentes mientras la autoridad digital para coordinarlos desapareció.
- La empresa implementó extensos workarounds manuales y reconstruyó la infraestructura a una velocidad excepcional. El presidente de Maersk describió más tarde la reinstalación de 4.000 servidores, 45.000 computadoras y 2.500 aplicaciones en diez días. Una reconstrucción periodística detallada dice que un controlador de dominio desconectado en Ghana suministró los datos de identidad necesarios para reiniciar los servicios centrales; ese relato es importante pero no es un informe forense oficial.
- Maersk reportó finalmente un efecto en la rentabilidad de 250-300 millones de dólares, principalmente por negocio temporalmente perdido en julio y agosto, junto con costos de restauración y operativos extraordinarios. Esa cifra mide el impacto reconocido por la empresa, no las pérdidas completas de camioneros, transitarios, propietarios de carga, agencias públicas o pequeñas empresas aguas abajo.
- La responsabilidad tiene capas. Los actores militares rusos posteriormente atribuidos y acusados en relación con NotPetya tienen la responsabilidad del ataque destructivo. Maersk seguía siendo responsable de la resiliencia de los sistemas bajo su control, de las afirmaciones de continuidad hechas a los clientes y de demostrar que la remediación abordó los caminos por los cuales una dependencia regional de software se convirtió en una falla operativa global.
- La lección duradera no es simplemente mantener copias de seguridad. Un operador crítico debe poder recuperar identidad, configuración, datos operativos y comunicaciones en un entorno limpio; ejecutar procesos manuales acotados sin perder seguridad o integridad de la carga; y brindar a los organismos públicos y a los clientes más pequeños información oportuna y portátil suficiente para activar sus propios planes de continuidad.
Un operador global perdió la capacidad de decir qué debería moverse a continuación
El martes 27 de junio de 2017, A.P. Moller - Maersk fue una de muchas organizaciones afectadas por un malware que parecía ransomware pero se comportaba como un instrumento destructivo. Las imágenes inmediatas fueron familiares de un incidente cibernético de oficina: las pantallas se oscurecieron, las aplicaciones se detuvieron, los empleados perdieron el acceso. La consecuencia no se limitó a las oficinas. Maersk conectaba el transporte marítimo, las terminales portuarias y el transporte de carga a través de jurisdicciones y zonas horarias.
Cuando las aplicaciones compartidas y los servicios de identidad dejaron de estar disponibles, la interrupción llegó a los puntos donde un camión entra a una terminal, una reserva se convierte en un movimiento de carga y un manifiesto electrónico le dice al operador qué hay dentro de un buque.
La presentación para inversores del segundo trimestre de 2017 de la empresa proporciona el relato conciso más firme. Maersk dijo que el malware entró a través de un software utilizado para declarar impuestos en Ucrania, hizo que las aplicaciones y los datos no estuvieran disponibles, y afectó principalmente a sus negocios relacionados con contenedores: Maersk Line, APM Terminals y Damco. Dijo que varios sistemas fueron apagados como precaución, que se introdujeron muchos workarounds manuales y que se mantuvo el control total de los buques.
También dijo que hubo una interrupción significativa que afectó a empleados y clientes, aunque no reportó violación de datos de terceros ni pérdida de datos.
Esas declaraciones establecen un límite esencial. Esto no fue reportado públicamente como una pérdida de navegación o propulsión, y un análisis no debe convertir una interrupción comercial y de terminal severa en una emergencia ficticia de control de buques. Sin embargo, la supervivencia del control de los buques no significó que el servicio de envío sobreviviera intacto. Un buque puede ser navegable de manera segura mientras la red a su alrededor no puede aceptar su próxima carga, leer los archivos necesarios para trabajar su carga, liberar contenedores a los camioneros o proporcionar un estado confiable a los clientes.
La resiliencia operativa tiene varias capas, y el estado seguro de una capa no confiere continuidad a las demás.
El incidente pasó rápidamente de una exposición local de software a una interrupción empresarial. El relato técnico contemporáneo de Microsoft sobre el brote de Petya observó una ruta inicial de cadena de suministro a través del actualizador de M.E.Doc y describió el movimiento lateral utilizando robo de credenciales y suplantación, así como la explotación de la vulnerabilidad SMB abordada por MS17-010. Un análisis de red posterior de Microsoft caracterizó la propagación como sofisticada y bien probada. El punto práctico no es que un parche faltante explique a Maersk. La evidencia pública no respalda esa conclusión ordenada.
NotPetya podía usar más de una ruta, incluyendo credenciales legítimas, por lo que la exposición dependía del privilegio de identidad, la alcanzabilidad de la red, la segmentación, la confianza del software y la velocidad de contención, así como del estado de vulnerabilidad.
Para el 30 de junio, el panorama operativo estaba mejorando pero aún era desigual. Una actualización de APM Terminals dijo que estaba expandiendo los servicios de puerta en una lista de puertos que incluía Los Ángeles. Una actualización pública de ese tipo es valiosa porque expone la unidad real de recuperación: no «TI está de vuelta», sino una puerta o servicio de terminal particular en un lugar particular. La restauración global fue un portafolio de estados locales. Algunos sitios podían trabajar carga, otros podían ofrecer puertas limitadas, y los sistemas orientados al cliente se recuperaron en su propio cronograma.
El informe financiero posterior de la empresa confirma que esto fue más que un inconveniente técnico corto. Su informe intermedio del tercer trimestre de 2017 situó el efecto en la rentabilidad en 250-300 millones de dólares, con la gran mayoría relacionada con Maersk Line en el tercer trimestre. Dijo que los volúmenes transportados cayeron un 2,5 por ciento en comparación con el trimestre comparable y se vieron afectados negativamente por el ataque, y describió la mayor parte del impacto financiero como negocio temporalmente perdido en julio y agosto.
El capital de trabajo también se vio afectado, mientras que APM Terminals y Damco registraron efectos relacionados con el ataque.
Ese período contable importa. La interrupción más visible se desarrolló en días, pero las consecuencias comerciales persistieron después de que las aplicaciones comenzaron a regresar. Los contenedores y los horarios no vuelven instantáneamente a sus posiciones anteriores cuando se inicia un servidor. Las reservas perdidas durante la incertidumbre no se restauran reiniciando un portal. Un cliente que desvía carga, un camionero que pierde un turno o un fabricante que paga por otra ruta crea una consecuencia que vive más allá de la restauración técnica.
Por lo tanto, el tiempo de recuperación debe medirse por separado para infraestructura, aplicaciones, sitios, atrasos de transacciones y clientes.
El ataque fue destructivo, no una negociación de rescate ordinaria
Llamar al evento ransomware puede oscurecer las decisiones que enfrentaron los defensores y ejecutivos. NotPetya mostraba una demanda de pago, pero su diseño y la atribución oficial posterior respaldan tratarlo como malware destructivo. La declaración de atribución del Reino Unido de 2018 consideró responsable al gobierno ruso, específicamente a los militares rusos, y dijo que el ataque se disfrazó de empresa criminal mientras su propósito principal era la disrupción. En 2020, el Departamento de Justicia de Estados Unidos acusó a seis oficiales del GRU ruso en relación con una campaña que incluía NotPetya.
Esas acusaciones son acusaciones, no condenas, pero son una acción formal de responsabilidad y el departamento describió explícitamente el malware como destructivo.
Esta distinción cambia la estrategia de recuperación. En un escenario de extorsión ordinaria, los líderes aún pueden debatir si existe un descifrador, si se robaron datos y si el pago podría alterar el resultado. Con un evento destructivo, la preservación y la reconstrucción limpia se vuelven centrales. Restaurar una máquina aparentemente funcional no es suficiente si las credenciales privilegiadas, las rutas de distribución de software o las imágenes confiables pueden estar comprometidas.
La organización debe establecer un plano de control limpio desde el cual pueda reconstruir, restablecer la confianza y decidir qué datos son seguros de reintroducir.
También cambia la equidad del análisis de responsabilidad. Maersk no eligió ser atacada, y la entidad que libera un gusano destructivo es responsable por el daño previsible e imprudente que causa más allá de un objetivo previsto. La responsabilidad de la víctima no sustituye la responsabilidad del atacante. Ambas coexisten porque diferentes actores controlaron diferentes partes de la cadena causal. Los actores estatales controlaron la decisión de desplegar código destructivo. El proveedor de software controló su entorno de actualización.
Maersk controló cómo una dependencia comercial ucraniana se conectaba con su patrimonio global, cómo se protegían los límites de identidad y red privilegiados, y qué tan recuperables eran sus servicios críticos.
El registro público no es una evaluación forense completa de esos controles. Los archivos de Maersk identifican la ruta de entrada y los efectos, pero no publican una ruta de propagación dispositivo por dispositivo, inventario de parches, gráfico de privilegios o hallazgo independiente sobre qué salvaguardas fallaron. Reportajes posteriores han proporcionado detalles importantes, pero un argumento de responsabilidad no debe llenar los vacíos restantes con conjeturas seguras. Es justo preguntar por qué un punto final infectado pudo contribuir a una pérdida empresarial generalizada.
No es justo afirmar, sin el registro interno, que un empleado específico, una máquina sin parche o una configuración de producto fueron la causa única.
La mejor pregunta de gobernanza es sobre los dominios de falla. Una multinacional a veces debe ejecutar software requerido localmente, incluyendo herramientas fiscales y aduaneras que nunca serían seleccionadas como un estándar tecnológico global. La necesidad local no justifica la confianza global. Los sistemas con propósitos regionales estrechos deben colocarse en una arquitectura que asuma que sus canales de actualización pueden fallar: privilegios restringidos, egreso controlado, alcanzabilidad limitada, ejecución monitoreada, credenciales administrativas separadas y aislamiento rápido.
Si el negocio no puede eliminar la exposición, puede reducir la autoridad que esa exposición tiene sobre todo lo demás.
La capacidad física y la autoridad digital quedaron separadas
La logística de contenedores hace que la diferencia entre activos y autoridad sea inusualmente visible. Los barcos, grúas, contenedores, chasis, puertas y almacenes son físicos. Su operación eficiente depende de registros digitales que responden preguntas básicas pero consecuentes: ¿Qué caja es esta? ¿Está despachada? ¿A dónde debe ir? ¿Es seguro levantarla? ¿Qué cliente tiene autoridad para recogerla? ¿Qué buque y viaje deben recibirla? ¿Qué condiciones peligrosas, refrigeradas o sensibles al tiempo se aplican?
Una reconstrucción de WIRED de NotPetya y la recuperación de Maersk reportó que 17 de las 76 terminales de APM Terminals se vieron afectadas, que las puertas y algunas operaciones de grúa se detuvieron, y que el sitio central de reservas no estaba disponible. Describió terminales que perdieron acceso a archivos electrónicos que identificaban el contenido de los buques, colas de camiones en Elizabeth, Nueva Jersey, y clientes que luchaban por localizar o redirigir carga. Esto es evidencia narrativa profundamente reportada basada en entrevistas, no un informe forense de un regulador.
Sus afirmaciones internas específicas deben atribuirse en consecuencia, mientras que su relato amplio es consistente con las revelaciones de Maersk de interrupción significativa del cliente y volúmenes perdidos.
La falla revela por qué «el puerto permaneció abierto» es una medida de continuidad inadecuada. Una autoridad portuaria propietaria, servicio de aduanas, operador de terminal, línea naviera, operador ferroviario y camionero pueden estar todos técnicamente disponibles mientras un movimiento de carga sigue siendo imposible. La transacción requiere varios permisos y registros que coincidan. Si un participante controla el estado de carga autoritativo y ese estado no está disponible, la capacidad física de repuesto en otro lugar puede no ayudar.
Por el contrario, la disponibilidad digital sin estado confiable puede ser peligrosa. Una terminal no debe mover un contenedor simplemente porque una grúa puede alcanzarlo. El manejo manual debe preservar las restricciones de peso, mercancías peligrosas, aduanas, reefer, propiedad y estiba. La presión de «mantener la carga en movimiento» no puede anular la información requerida para un movimiento seguro y legal. Por lo tanto, un modo manual resiliente no es una instrucción genérica de usar papel.
Es un servicio deliberadamente restringido con transacciones definidas, datos de referencia disponibles de forma independiente, dobles verificaciones, identificadores de conciliación y condiciones de parada claras.
Maersk reportó que introdujo un gran número de workarounds manuales. El relato de WIRED describe correo electrónico personal, mensajería, hojas de cálculo y papel adjunto a los contenedores. Tal improvisación puede ser un puente racional durante una emergencia sin precedentes, y habla del ingenio de los empleados. También crea riesgos de integridad, privacidad, autorización y conciliación. Un mensaje recibido en una cuenta de emergencia puede ser auténtico, equivocado o malicioso. Una hoja de cálculo puede preservar una reserva pero omitir un campo de carga peligrosa.
Una liberación en papel puede permitir el movimiento mientras crea transacciones duplicadas o no facturadas más tarde.
La lección de responsabilidad no es prohibir la improvisación. Es convertir las mejores prácticas de emergencia en capacidad controlada antes del próximo incidente. Un servicio mínimo viable de terminal debe especificar qué clases de carga pueden moverse, qué datos independientes deben estar presentes, quién puede aprobar una excepción, cómo cada acción manual obtiene un registro único, cómo se contacta a las autoridades públicas y cómo se conciliarán los registros una vez que los sistemas regresen. La capacidad debe probarse en camiones o contenedores por hora, no describirse solo como «respaldo manual disponible».
La recuperación dependió de la reconstrucción de la confianza
La parte más memorable de la historia de Maersk se refiere a Active Directory. En la reconstrucción de WIRED, aproximadamente 150 controladores de dominio se habían sincronizado entre sí y fueron borrados, mientras que inicialmente no se pudo encontrar una copia de seguridad utilizable por separado de esa capa de identidad. Un controlador de dominio en Ghana había sido desconectado durante un corte de energía y sobrevivió. El ancho de banda limitado hizo que la transferencia remota fuera impráctica, por lo que los empleados supuestamente trasladaron una unidad a través de Nigeria hasta el centro de recuperación en Inglaterra.
Este relato a menudo se ha reducido a una anécdota sobre la buena suerte. Su significado más profundo es que la identidad era un requisito previo para todo lo demás. Una empresa puede poseer copias de seguridad de datos de aplicaciones y aún así no poder restaurar las operaciones si no puede recrear usuarios, máquinas, permisos, cuentas de servicio y autoridad administrativa de confianza. El sistema de identidad no es solo otra aplicación. Es parte de la maquinaria que declara qué componentes restaurados pueden comunicarse y actuar.
La historia también distingue la replicación de la copia de seguridad. Múltiples controladores de dominio sincronizados mejoran la disponibilidad contra fallas de hardware ordinarias. No crean recuperación independiente si el estado destructivo puede alcanzar todas las réplicas. La redundancia responde «¿puede otro nodo en vivo servir?» La copia de seguridad responde «¿puede la organización volver a un estado anterior conocido y bueno después de que todos los nodos en vivo dejen de ser confiables?» Una copia que comparte el mismo plano administrativo, conectividad y ruta destructiva puede ser redundante pero no recuperable.
La orientación moderna hace explícita esa independencia. El Centro Nacional de Seguridad Cibernética del Reino Unido recomienda copias de seguridad fuera de línea o segregadas, múltiples copias, restauración probada y recuperación limpia. La guía de planificación de contingencia de NIST trata la recuperación como una combinación coordinada de planes, procedimientos y medidas técnicas, incluyendo equipos alternativos, procesamiento manual y ubicaciones alternativas. Ninguno de estos documentos prueba lo que Maersk tenía en 2017. Proporcionan una forma disciplinada de evaluar lo que mostró el evento.
Para un operador logístico global, el conjunto recuperable tiene al menos cuatro partes. Primero, la identidad y el plano de control administrativo. Segundo, la configuración de infraestructura: definiciones de red, seguridad, nube, punto final y plataforma que pueden reconstruirse sin confiar en el patrimonio dañado. Tercero, el estado operativo: reservas, manifiestos, ubicación de contenedores, estado aduanero, atributos de mercancías peligrosas, asignaciones de equipos e instrucciones del cliente.
Cuarto, el mapa de relaciones externas: contactos y canales verificados para puertos, autoridades, proveedores, clientes, bancos y socios de emergencia.
Cada parte necesita su propio objetivo de punto de recuperación y tiempo de recuperación. Una copia de seguridad del servidor de tres días puede ser aceptable para un servicio de referencia estático e inaceptable para eventos de contenedores que cambian minuto a minuto. Una copia de seguridad de identidad limpia puede restaurar el acceso pero no decirle a una terminal qué transacciones ocurrieron manualmente durante la interrupción. Una lista de contactos de clientes almacenada detrás del proveedor de identidad fallido puede estar completa pero ser inútil.
«Las copias de seguridad se realizaron correctamente» es, por lo tanto, una métrica pobre para la junta directiva. La evidencia útil es si los servicios representativos se han reconstruido a partir de entradas protegidas dentro de un entorno limpio, a escala, dentro del período que la red operativa y sus clientes pueden tolerar.
Diez días fue un logro, no un veredicto completo de resiliencia
En el Foro Económico Mundial en enero de 2018, el presidente de Maersk, Jim Hagemann Snabe, describió un esfuerzo notable: reconstruir 4.000 servidores, 45.000 computadoras personales y 2.500 aplicaciones en diez días. La escala es ampliamente citada porque captura el trabajo y la urgencia de la respuesta. El relato posterior de WIRED dice que algunos trabajos de recuperación continuaron mucho más tiempo, lo que es compatible con una distinción entre reconstruir el patrimonio central y completar cada restauración de aplicación o usuario.
El informe anual 2017 de Maersk calificó la recuperación como rápida y reportó pérdidas de 250-300 millones de dólares que cubren ingresos, restauración de TI y costos operativos extraordinarios. Dijo que se habían implementado o planificado iniciativas inmediatas y a largo plazo para asegurar el negocio digital, fortalecer la plataforma de infraestructura, mejorar la continuidad y recuperación del servicio de TI, y reforzar los planes de continuidad del negocio. La empresa también contrató un seguro cibernético.
Esa es una respuesta de gestión creíble, pero no hace que la velocidad de recuperación sea un veredicto suficiente sobre la resiliencia previa al incidente o la garantía posterior al incidente. La recuperación heroica y la resiliencia diseñada son cualidades diferentes. La recuperación heroica se basa en personas excepcionales, compras de emergencia, autoridad ejecutiva amplia, soporte de proveedores y esfuerzo sostenido. La resiliencia diseñada hace que los resultados críticos dependan menos de condiciones excepcionales.
Estrecha el radio de explosión, preserva el material de recuperación confiable, preacuerda la capacidad y proporciona decisiones practicadas antes de que la fatiga y la incertidumbre se afiancen.
La distinción importa para la responsabilidad de los empleados. El elogio por el trabajo extraordinario puede normalizar silenciosamente un modelo operativo que requiere trabajo extraordinario. Las juntas directivas deben preguntar cuántas personas trabajaron horas inseguras, qué roles no tenían un suplente capacitado, qué pasos de recuperación dependían del conocimiento personal y si la autoridad de emergencia se documentó después del hecho. Un programa de resiliencia debe preservar el conocimiento improvisado revelado por una crisis mientras reduce la necesidad de repetir la carga física y psicológica.
Importa también para la responsabilidad financiera. La estimación de 250-300 millones de dólares no es un total de daños globales. Maersk describió lo que el ataque costó a su propia rentabilidad. No captura cada giro de camión no compensado, reserva de almacén, espacio de producción perdido, artículo estropeado, compra pública retrasada o tensión de capital de trabajo experimentada por clientes y proveedores de servicios.
El informe de WIRED cita a camioneros y empresas de logística que dijeron que sufrieron pérdidas sustanciales, pero ningún conjunto de datos auditados respalda agregar esas anécdotas en un número único para toda la economía.
El seguro también transfiere solo consecuencias financieras específicas. No restaura un envío de medicamentos, preserva el cliente de un pequeño importador ni le da a una autoridad portuaria visibilidad de carga en tiempo real. Una junta que reporta límites de seguro sin reportar evidencia de recuperación operativa está midiendo la protección del balance general en lugar de la resiliencia del servicio. Ambos importan, pero no son sustitutos.
La responsabilidad sigue al control, no a la proximidad al malware
La frase «Maersk fue una víctima» es cierta e incompleta. También lo es «Maersk debería haber estado preparada». Una asignación útil de responsabilidad identifica las decisiones que cada actor podía tomar antes, durante y después del evento.
| Actor | Control antes de la interrupción | Deber durante la interrupción | Evidencia debida después |
|---|---|---|---|
| Actores estatales maliciosos | Decisión de desarrollar y liberar malware destructivo | Detener la actividad dañina y evitar la propagación indiscriminada | Procesos penales, diplomáticos y de responsabilidad estatal; preservación de evidencia |
| Proveedor de software | Seguridad de los entornos de compilación, actualización y administración | Advertencia rápida, aislamiento, indicadores y cooperación | Hallazgos de incidentes independientes y remediación de la cadena de suministro |
| Liderazgo del grupo Maersk | Apetición al riesgo, inversión, arquitectura, objetivos de recuperación e incentivos ejecutivos | Comandar el incidente, proteger la vida y la seguridad, comunicar estados de servicio materiales | Relato causal, impacto al cliente, propiedad de la remediación y resultados de resiliencia verificados |
| Propietarios de tecnología y negocio | Segmentación, identidad, parches, copias de seguridad, mapeo de servicios y procedimientos manuales | Contener, preservar evidencia, reconstruir limpiamente y mantener operaciones acotadas | Resultados de pruebas para las rutas de falla reales y excepciones no resueltas |
| Socios de terminales y puertos | Continuidad local, reglas de carga segura, coordinación con agencias públicas y canales alternativos | Controlar puertas, colas, seguridad de la carga y estado local | Capacidad específica del sitio, conciliación y hallazgos de ejercicios conjuntos |
| Autoridades públicas | Requisitos de continuidad, política de carga prioritaria, coordinación entre operadores e información pública | Mantener seguridad, aduanas y decisiones de emergencia a través de canales independientes | Hallazgos posteriores a la acción, remediación de dependencias y supervisión proporcional |
| Clientes e intermediarios logísticos | Mapeo de rutas críticas, inventario, exportaciones de datos, contactos alternativos y contratos | Proteger la carga, priorizar pedidos, documentar pérdidas y comunicar aguas abajo | Planes de continuidad actualizados y escenarios de falla del proveedor probados |
Esta asignación evita convertir al administrador más cercano en el centro moral de un evento sistémico. Si un empleado local debía usar software de impuestos ucraniano, esa persona no decidió la arquitectura de confianza global. Si un empleado de terminal usó un canal personal para rescatar un envío, esa acción debe revisarse por riesgo y aprenderse, no aislarse de las condiciones que la hicieron necesaria. La responsabilidad superior comienza donde reside la autoridad sobre arquitectura, presupuesto, aceptación de riesgos y promesas de servicio.
También evita excusar a las organizaciones aguas abajo. Una agencia pública o un pequeño importador no puede rediseñar el sistema de identidad de un transportista. Puede decidir si su propio plan de continuidad asume que el portal, el equipo de cuentas y la terminal del transportista estarán todos disponibles juntos. Puede mantener identificadores de envío y documentos esenciales fuera del portal del proveedor, acordar contactos de emergencia, clasificar qué bienes justifican un enrutamiento alternativo y comprender cuánto tiempo su inventario o compromiso de servicio puede absorber un retraso.
La responsabilidad debe ser proporcional. Una pequeña empresa no puede mantener económicamente reservas duplicadas en cada ruta ni reservar carga aérea para carga ordinaria. Un comprador municipal no puede comandar la secuencia de recuperación de un transportista global. El estándar no es redundancia infinita. Es la selección consciente de medidas de continuidad basadas en la consecuencia, la sensibilidad al tiempo, la sustituibilidad y los recursos disponibles.
Los puertos convierten la falla privada en un problema de continuidad pública
Los puertos son ecosistemas institucionales. Las autoridades portuarias públicas, las aduanas y agencias fronterizas, la policía, los inspectores de salud y agricultura, las terminales operadas privadamente, los transportistas, los ferrocarriles, los camioneros y los transitarios comparten el mismo espacio físico e informativo. Una falla originada en la red empresarial de una empresa puede, por lo tanto, crear tareas públicas incluso cuando ningún sistema gubernamental se ve comprometido.
La revisión de 2025 de la Oficina de Responsabilidad Gubernamental de EE. UU. sobre ciberseguridad marítima usa NotPetya como ejemplo prominente, reportando que las computadoras de Maersk se apagaron, las operaciones portuarias incluyendo las de EE. UU. se detuvieron y los barcos quedaron inactivos en el mar. El informe también encontró brechas más amplias en el proceso de lista de incidentes, la planificación estratégica y las prácticas de la fuerza laboral cibernética de la Guardia Costera.
La importancia es institucional: el sector público no puede cumplir con las responsabilidades de seguridad marítima y continuidad asumiendo únicamente que cada operador privado ha gestionado sus propias dependencias.
La línea base de política internacional ya se estaba moviendo cuando golpeó NotPetya. Diez días antes del ataque, la Organización Marítima Internacional adoptó la Resolución MSC.428(98), alentando a que el riesgo cibernético se aborde en los sistemas de gestión de seguridad para la primera verificación anual después del 1 de enero de 2021. Las directrices de riesgo cibernético marítimo de 2017 asociadas organizaron la acción en torno a identificar, proteger, detectar, responder y recuperar, con participación de la alta dirección y continuidad de las operaciones de envío.
Esos instrumentos no deben aplicarse incorrectamente. Son guías de seguridad marítima de alto nivel, no un hallazgo retrospectivo de que Maersk violó una regla específica de TI de terminal en junio de 2017. Su momento sí muestra que el riesgo cibernético para el transporte marítimo no fue inventado por NotPetya. El incidente aceleró una pregunta de responsabilidad que el sector ya estaba enfrentando: cómo conectar la gobernanza cibernética con los sistemas de seguridad y continuidad que los líderes marítimos ya entienden.
Las guías posteriores se han vuelto más operativas. Las directrices de riesgo cibernético para puertos de la Agencia de la Unión Europea para la Ciberseguridad mapean las prácticas de riesgo a los procesos de seguridad portuaria y enfatizan un ciclo de evaluación adaptable. El manual de resiliencia portuaria de la Conferencia de las Naciones Unidas sobre Comercio y Desarrollo trata a los transportistas, aduanas, transitarios, propietarios de carga y operadores logísticos terrestres como partes interesadas colaboradoras.
Señala que las mercancías containerizadas representan una parte mucho mayor del comercio marítimo por valor que por volumen y que los puertos pueden convertirse en puntos únicos de falla.
La planificación de continuidad pública debe traducir esos principios en preguntas operativas. ¿Qué datos mínimos de carga pueden usar las aduanas y una terminal si la plataforma del transportista no está disponible? ¿Puede un puerto autenticar instrucciones de emergencia a través de un canal independiente del sistema de identidad del operador afectado? ¿Quién gestiona las colas de camiones cuando fallan los sistemas de citas y puertas? ¿Cómo se prioriza la carga refrigerada, peligrosa, médica, alimentaria y de servicio público sin permitir que la prioridad autodeclarada abrume el proceso?
¿Cuándo se suspenderán las reglas de almacenamiento, demora o acceso, y quién puede anunciar esa decisión?
La respuesta correcta rara vez es una hoja de cálculo compartida gigante esperando un desastre. Un respaldo central puede convertirse en otra falla común y una fuente tentadora de datos comerciales sensibles. Una mejor continuidad utiliza conjuntos de datos mínimos acordados, formatos interoperables, extractos locales protegidos, autoridad legal clara, rutas de comunicación probadas y una forma federada de conciliar eventos. El papel del sector público es convocar y probar las interfaces que ninguna empresa posee por sí sola.
La digitalización portuaria hace esto más urgente. El Banco Mundial describe los sistemas comunitarios portuarios como plataformas colaborativas que conectan aduanas, gestión portuaria, transportistas, empresas de logística y transitarios. Dichos sistemas pueden reducir costos y mejorar la resiliencia, especialmente para participantes más pequeños, pero su valor aumenta la consecuencia de una falla o mala integración. La arquitectura de eficiencia necesita una arquitectura de degradación: una respuesta sobre qué puede ver y hacer cada participante cuando la plataforma compartida o un contribuyente importante desaparece.
Las pequeñas empresas absorben los retrasos de manera diferente
La interrupción de Maersk alcanzó a las pequeñas empresas en varios roles: transitarios que organizan envíos, empresas de camiones que sirven terminales, agentes de aduanas, operadores de almacenes, exportadores, importadores y empresas que esperan insumos. Algunos eran clientes directos; otros dependían económicamente del rendimiento de la terminal sin un contrato que prometiera compensación. Su problema de continuidad difería del de Maersk. No necesitaban reconstruir miles de servidores. Necesitaban estado autoritativo, acceso a la carga, una alternativa creíble y suficiente efectivo para sobrevivir la espera.
Las pequeñas empresas están estructuralmente expuestas a la incertidumbre logística. El trabajo de la OCDE sobre PYMEs y comercio señala que las empresas más pequeñas tienen menos recursos para enfrentar costos transfronterizos y pueden verse afectadas desproporcionadamente por las barreras comerciales, mientras que la facilitación del comercio y la conectividad ayudan a apoyar la entrega oportuna. Una interrupción que agrega llamadas telefónicas, almacenamiento, documentación duplicada, transporte de emergencia y fechas de liberación inciertas impone más que un retraso de tiempo.
Agrega costos de coordinación fijos que son más difíciles de distribuir entre el volumen.
La concentración de proveedores tiene dos significados para una PYME. Puede haber solo un transportista o terminal comercialmente sensato para una ruta, y varios servicios aparentemente separados pueden depender del mismo plano de control digital del operador. Comprar transporte marítimo a través de un transitario no necesariamente crea una ruta independiente si la reserva, la terminal y la cadena de estado del cliente convergen en el mismo transportista. El mapeo de continuidad debe seguir la ruta real de movimiento e información, no el número de facturas o intermediarios.
La respuesta práctica comienza con la custodia de datos. Un pequeño importador debe conservar referencias de reserva, facturas y documentos comerciales, números de contenedor y precinto, estado aduanero, requisitos peligrosos o refrigerados, contactos e hitos prometidos en un lugar que no requiera abrir el portal del transportista. Esto no es un intento de duplicar la base de datos operativa del proveedor. Es el paquete mínimo necesario para identificar el envío, probar la autoridad y pedir ayuda a otra parte.
Luego viene el triaje. Las empresas deben decidir de antemano qué carga puede esperar, cuál puede usar otro viaje, cuál amenaza la producción o un compromiso público, y cuál podría justificar una costosa sustitución por aire o carretera. La respuesta debe incluir una autoridad de gasto. Durante el evento de Maersk, las alternativas escasas y la información incierta forzaron decisiones bajo presión. Un umbral preacordado permite que un líder de operaciones actúe antes de que se pueda contactar a un fundador, oficial financiero o cliente público.
La comunicación necesita la misma independencia que la copia de seguridad. El Centro Nacional de Seguridad Cibernética del Reino Unido ofrece una guía de respuesta y recuperación para pequeñas empresas que enfatiza la preparación, roles, contactos, resolución, informes y aprendizaje. Para un evento de dependencia logística, la hoja de contactos debe extenderse más allá de los respondedores cibernéticos internos. Debe incluir la ruta de emergencia del transportista, terminal, transitario, corredor, almacén, aseguradora, banco, clientes críticos y la autoridad pública relevante.
Una copia impresa o almacenada de forma independiente importa cuando el correo electrónico o el inicio de sesión único es parte de la falla.
Finalmente, el contrato debe decir cómo se ve la equidad operativa. Los canales de notificación, el acceso a datos, las exenciones de tarifas durante puertas inaccesibles, las responsabilidades de preservación de la carga, la documentación para reclamos y las rutas de escalada son más útiles que una promesa amplia de alta disponibilidad. No todos los clientes pequeños pueden negociar términos personalizados, por lo que las autoridades portuarias, reguladores, asociaciones comerciales y grandes proveedores de logística tienen un papel en la estandarización de protecciones. El objetivo no es una compensación garantizada por cada retraso.
Es un proceso predecible que no obligue a la parte menos poderosa a probar una interrupción que el operador ya sabe que ocurrió.
Los recursos generales de preparación siguen siendo relevantes. Ready Business combina comunicaciones, recuperación de TI, planes de continuidad, capacitación y ejercicios, en lugar de tratar la recuperación cibernética como un plan técnico aislado. La guía de CISA para líderes corporativos dice de manera similar centrar la inversión en resiliencia en las funciones comerciales críticas y probar la continuidad después de una intrusión.
Para una pequeña empresa, el ejercicio puede ser modesto: una hora en la que el equipo asume que el portal del transportista, el representante de cuentas y la terminal principal no están disponibles, luego intenta localizar dos envíos prioritarios y tomar una decisión documentada de redireccionamiento.
La continuidad manual debe tener un límite de diseño
Los workarounds manuales de Maersk son justamente admirados porque preservaron gran parte del servicio mientras se reconstruía el patrimonio digital. También muestran por qué la continuidad manual no puede describirse como un sustituto ilimitado. El rendimiento humano es menor, los errores son más difíciles de detectar y los registros necesarios para la conciliación posterior se multiplican rápidamente. Cuanto más dure el modo degradado, más su propio atraso y deuda de control se convierten en un problema de recuperación.
Un plan manual creíble tiene un alcance y duración máximos. Identifica las funciones que deben continuar, las que pueden pausarse y las que no deben intentarse sin sistemas. Asigna la capacidad escasa según la seguridad y la consecuencia. Establece cómo se autoriza, registra y verifica una transacción. Mantiene un reloj y secuencia de incidentes únicos incluso si los equipos locales usan diferentes herramientas. Reserva personas para la conciliación, porque cada registro temporal eventualmente tendrá que encontrarse con el sistema restaurado.
El plan también debe sobrevivir a la pérdida de la tecnología de trabajo ordinaria. Los formularios de emergencia almacenados en el mismo recurso compartido de archivos, las listas de contactos detrás del mismo proveedor de identidad y los puentes de conferencia que dependen de la misma red no son activos de continuidad. El Centro Nacional de Seguridad Cibernética del Reino Unido aconseja a las organizaciones mantener copias de seguridad limpias, dispositivos de repuesto y registros utilizables; el principio más amplio es que los respondedores necesitan un conjunto de herramientas mínimo independiente.
Para una empresa de logística distribuida, esto puede incluir computadoras portátiles limpias, comunicaciones separadas, identidades externas preaprobadas, repositorios de configuración protegidos y kits de recuperación regionales.
Las operaciones manuales deben ejercitarse con las partes que las reciben. Una terminal puede producir una liberación en papel, pero no tiene valor de continuidad si el personal de puerta, la aduana o un camionero no pueden validarla. Un transportista puede aceptar una reserva por correo electrónico de emergencia, pero la reserva no es segura si las declaraciones de mercancías peligrosas no pueden seguir. Una autoridad pública puede crear una lista de prioridades, pero fallará si no hay una forma verificada de hacer coincidir esa lista con los contenedores.
Los ejercicios conjuntos descubren estas fallas de interfaz antes de que un incidente cree presión comercial para pasarlas por alto.
Las métricas de capacidad deben ser honestas. «Las terminales pueden operar manualmente» dice poco. Una declaración más sólida es que un sitio específico puede procesar de manera segura una categoría definida de movimientos a un porcentaje medido del rendimiento normal durante un cierto número de horas, con una carga de conciliación conocida y exclusiones claras. Publicar todos los detalles podría crear riesgo de seguridad o comercial, pero las juntas directivas y las autoridades relevantes deben ver la evidencia.
Lo que una junta directiva debe pedir ver
Después de NotPetya, Maersk dijo que fortaleció la resiliencia cibernética, la infraestructura, la continuidad del servicio, la recuperación y la continuidad del negocio. Los informes públicos no revelan suficientes detalles para verificar de forma independiente el estado actual de cada medida, y la ausencia de detalles no es evidencia de que el trabajo no se haya realizado. Significa que los lectores externos deben distinguir un programa declarado de resultados probados.
El primer artefacto de la junta debe ser un mapa de servicios, no un recuento de activos. Debe comenzar con resultados como aceptar una reserva, admitir un camión, leer datos de carga del buque, liberar un contenedor, monitorear un reefer y comunicar el estado. Para cada resultado debe identificar las dependencias de identidad, red, aplicación, datos, instalaciones, proveedores y agencias públicas. El mapa debe exponer cuándo múltiples resultados comparten un plano administrativo o una ruta de confianza de software local.
El segundo artefacto debe ser evidencia de recuperación destructiva. ¿Puede la organización construir un entorno de identidad limpio sin ningún servicio empresarial en vivo? ¿Se restauran las credenciales, claves, confianza del dispositivo, configuración y estaciones de trabajo privilegiadas en un orden controlado? ¿Las copias de seguridad son inaccesibles para los administradores comprometidos, se retienen el tiempo suficiente, se escanean y se prueban? ¿Se ha reconstruido una terminal o servicio de reservas representativo a partir de entradas protegidas a escala operativa?
El tercero debe ser evidencia de operación degradada. ¿Qué servicios pueden ejecutarse manualmente, a qué capacidad y con qué controles de seguridad? ¿Cuándo deja la empresa de aceptar nuevo trabajo para proteger la carga ya en su custodia? ¿Cómo se conciliarán los registros manuales? ¿Qué canales de comunicación permanecen si la identidad corporativa y la telefonía se pierden juntas? ¿Cuándo se ejercitó el plan por última vez con un puerto, un actor aduanero, un gran cliente y un pequeño proveedor de logística?
El cuarto debe ser datos de consecuencias de terceros. Debe mostrar no solo el tiempo de inactividad corporativo, sino también los movimientos de puerta rechazados, las reservas perdidas, la carga no localizada, las excepciones refrigeradas, los retrasos en el estado del cliente, las disputas de tarifas y los reclamos. Debe distinguir a los grandes clientes con soporte dedicado de los clientes más pequeños y los operadores indirectos. Un programa de recuperación que restaura los ingresos mientras deja a los clientes incapaces de obtener un estado autoritativo no ha completado la recuperación del servicio.
El quinto debe ser evidencia de cierre. Cada remediación debe identificar la ruta de falla observada, el propietario, la fecha de vencimiento, la prueba, la excepción y el revisor independiente. Los controles que reducen la probabilidad, como los parches y la segmentación, deben separarse de los controles que reducen la consecuencia, como la recuperación de identidad limpia y los modos manuales de terminal. El seguro cibernético debe informarse como transferencia financiera, no como remediación técnica.
El sexto debe ser aprendizaje sobre las personas. ¿Qué decisiones se retrasaron porque la autoridad no estaba clara? ¿Qué respondedores tenían conocimiento único? ¿Qué herramientas improvisadas resultaron útiles y cuáles crearon un riesgo inaceptable? ¿Cómo preservará la empresa la competencia de emergencia sin asumir que cientos de personas pueden sostener nuevamente una reconstrucción las 24 horas? La resiliencia operativa incluye personal, movilización de proveedores, visas, viajes, instalaciones, comida, descanso y sucesión, porque un diseño de recuperación limpio aún debe ser ejecutado por humanos.
La regulación se está poniendo al día con la realidad operativa
La gobernanza cibernética marítima se ha vuelto más concreta desde 2017. En Estados Unidos, la Regla de Ciberseguridad en el Sistema de Transporte Marítimo de la Guardia Costera entró en vigor el 16 de julio de 2025. Requiere que los buques e instalaciones cubiertas con bandera de EE. UU. reporten incidentes y establezcan gradualmente capacitación, un oficial de ciberseguridad designado, evaluación y un plan de ciberseguridad aprobado. La regla no hace imposible una repetición de NotPetya. Crea propiedad designada y planificación auditable donde la dependencia de la madurez voluntaria ya no se consideraba suficiente.
Los hallazgos de la GAO de 2025 son un recordatorio de que la regulación también necesita capacidad operativa. Los requisitos funcionan solo si la autoridad puede comprender los incidentes, mantener una base de evidencia confiable, coordinar localmente y probar si los planes abordan las dependencias reales. La resiliencia cibernética portuaria no se logra cuando cada entidad presenta un documento por separado. Surge cuando los planes se conectan en las interfaces compartidas donde la carga, la información de seguridad y la autoridad pública cruzan organizaciones.
Los reguladores también deben preservar la proporcionalidad. Un transportista global y un pequeño agente de aduanas no pueden llevar cargas de control idénticas. Se puede esperar razonablemente que los grandes operadores produzcan evidencia de recuperación independiente, mantengan capacidad de sala limpia y apoyen ejercicios conjuntos. Las pequeñas empresas necesitan seguridad básica, planes de continuidad utilizables y acceso a canales comunes. Los organismos públicos pueden reducir el costo colectivo definiendo conjuntos de datos mínimos, terminología común de incidentes, políticas de tarifas modelo y formatos de ejercicio.
La transparencia también debe calibrarse. Publicar una arquitectura de red o identidad completa crearía un nuevo riesgo. Publicar solo que «los sistemas están restaurados» crea muy poca responsabilidad. La divulgación útil incluye los servicios y ubicaciones afectados, los estados de recuperación limitados en el tiempo, las acciones del cliente, si la seguridad de la carga o la integridad de los datos están en cuestión, las categorías de causa raíz y falla de control, y cómo se garantizará la remediación de forma independiente. Los detalles sensibles específicos pueden permanecer con los reguladores o auditores.
La medida final es si la dependencia se volvió gobernable
La respuesta de Maersk en 2017 demostró una capacidad de recuperación formidable. Los empleados mantuvieron el control de los buques, improvisaron canales de servicio y reconstruyeron un vasto patrimonio tecnológico en condiciones extremas. La empresa absorbió un gran impacto financiero y posteriormente reportó inversión en resiliencia cibernética y continuidad. Esos hechos merecen peso.
No borran la señal central de responsabilidad. Una relación de software requerida localmente adquirió suficiente alcance práctico para ayudar a interrumpir las operaciones de contenedores en todo el mundo. La infraestructura de identidad replicada no proporcionó necesariamente recuperabilidad independiente. Los clientes y socios de terminales perdieron no solo el acceso a un sitio web, sino la información necesaria para coordinar el comercio físico. Los operadores más pequeños y las instituciones públicas tuvieron que gestionar consecuencias fuera de la pérdida reportada por Maersk.
La resiliencia operativa a menudo se describe como la capacidad de recuperarse. La frase es demasiado pasiva para la infraestructura de la que dependen otros. Un operador crítico debe decidir de antemano qué preservará, qué puede hacer de manera segura sin sus sistemas principales, cuyas necesidades serán priorizadas, cómo se comunicará la verdad y qué evidencia probará la recuperación. Sus clientes y socios públicos deben decidir qué harán cuando el propio operador sea la dependencia no disponible.
El valor perdurable del caso Maersk no es, por lo tanto, el espectáculo de 45.000 computadoras siendo reinstaladas. Es la exposición de una jerarquía oculta. La identidad tuvo que regresar antes de que las aplicaciones pudieran confiar entre sí. Los datos de carga tuvieron que regresar antes de que la capacidad física pudiera usarse de manera segura. El estado autoritativo tuvo que regresar antes de que los clientes pudieran tomar decisiones racionales. La conciliación tuvo que continuar después de que los sistemas estuvieran nominalmente disponibles. Cada capa tenía un reloj diferente.
Un régimen de responsabilidad maduro sigue esos relojes. No declara la victoria en el primer servidor restaurado, ni asigna la culpa a la primera oficina infectada, ni pide a los pequeños clientes que infieran la continuidad de una estimación financiera corporativa. Pregunta si la autoridad destructiva ha sido acotada, si la confianza de recuperación existe fuera del dominio de falla, si el servicio manual es seguro y medible, si las dependencias públicas y de PYME son visibles, y si la remediación ha sido probada por alguien capaz de desafiarla.
NotPetya fue un acto de agresión destructiva. El deber de Maersk no era hacer imposible tal agresión. Era, y sigue siendo, hacer que la dependencia de la confianza digital de la empresa sea gobernable: limitada antes de la falla, supervivible durante la falla, reconstruible después de la falla y legible para las instituciones y empresas que tienen que seguir operando cuando el transporte marítimo global pierde su memoria.

