Ransomware en 7 minutos, 495 empresas caídas: lo que el caso Japón enseña sobre integrar ISO 27001 e ISO 28000 en un solo mapa de riesgo.
Caso Japón: Por Qué Integrar ISO 27001 e ISO 28000 en un Solo Mapa de Riesgo
Un ransomware tumbó una región cloud completa en Japón en minutos y afectó a 495 organizaciones, muchas sin ser clientes directos del proveedor atacado. Qué exigen ISO 27001 e ISO 28000 frente al riesgo de cuarta parte.
El 7 de octubre de 2026, a las 3:40 de la madrugada hora de Japón, IDC Frontier (filial de SoftBank que opera la plataforma de infraestructura cloud IDCF Cloud) detectó un ataque de ransomware que forzó el apagado completo de su clúster de datacenters «East Japan Region 1». La empresa confirmó oficialmente que la interrupción fue causada por «un ataque de ransomware de un tercero» y desactivó el acceso a las consolas de administración en todas sus regiones mientras investigaba el alcance real del incidente. El atacante, en capturas de pantalla que circularon entre clientes y que IDC Frontier no ha confirmado, afirmó haber necesitado exactamente siete minutos para cifrar 225 sistemas de almacenamiento (3,6 petabytes de datos), acceder a 239 servidores de virtualización, sellar más de 16.000 discos de máquinas virtuales y borrar 554.153 copias de respaldo (snapshots).
Confirmado o no cada detalle técnico, el resultado medible es este: 495 empresas y organismos públicos quedaron afectados, según la propia IDC Frontier. Y acá está el dato que de verdad importa para quien gestiona sistemas de calidad, seguridad de la información o cadena de suministro: buena parte de esas 495 organizaciones no eran clientes directos del proveedor atacado. Dependían de él a través de un revendedor, un integrador de sistemas o una plataforma de software que a su vez corría sobre esa infraestructura. Es el riesgo de «cuarta parte»: el eslabón de la cadena que ni siquiera sabías que tenías.
Cómo se vio el riesgo de cuarta parte en la práctica
El caso japonés deja tres ejemplos concretos, de sectores muy distintos, que vale la pena mirar en detalle porque son exactamente el tipo de dependencia que un análisis de riesgo tradicional suele dejar fuera.
JR East (ferrocarriles) y su filial de tarjetas de crédito View Card advirtieron que hasta 6,09 millones de registros podrían haber sido accedidos, no porque JR East fuera cliente directo del proveedor atacado, sino porque usaba un servicio de envío de correos alojado en la infraestructura de IDC Frontier. JR Kyushu, por su parte, reportó 1,3 millones de correos expuestos por la misma vía. Ninguna de las dos empresas contrató directamente al proveedor que falló: contrataron un servicio de email marketing o notificaciones que, sin que lo supieran, corría sobre esa nube.
Nissui Logistics, operador de bodegas de alimentos congelados (parte del grupo Nissui), reportó una caída de sistemas por presunto acceso no autorizado a un centro de datos de terceros, con despachos y recepciones de mercadería completamente detenidos mientras investigaba una posible filtración de datos personales. Para una empresa de logística de cadena de frío, esto no es solo un problema informático: es inventario que no se puede mover y clientes que no reciben su carga.
La Policía de la Prefectura de Ibaraki también resultó afectada, junto con el sitio oficial del gobierno de esa prefectura. La Oficina Nacional de Ciberseguridad de Japón, creada el año pasado, envió una carta a los ministerios para distribuir a organismos públicos locales y empresas privadas, en la que remarca que la ciberseguridad «ya no es responsabilidad exclusiva del departamento de TI» y recomienda medidas básicas de protección, contraseñas robustas y, en particular, reforzar la seguridad de la cadena de suministro, advirtiendo que la inteligencia artificial está haciendo las vulnerabilidades más complejas de anticipar.
Qué exige ISO 27001 frente a este tipo de dependencia
El Anexo A de ISO/IEC 27001:2022 tiene un grupo de controles pensado exactamente para este escenario, el de una organización que depende de proveedores cuya infraestructura no controla ni, muchas veces, conoce en detalle:
- A.5.19 Seguridad de la información en las relaciones con proveedores. Exige identificar y evaluar los riesgos asociados a cada proveedor antes de contratarlo, y ese análisis debería incluir una pregunta simple que casi nadie hace: «¿sobre qué infraestructura corre este servicio, y qué pasa si esa infraestructura falla?».
- A.5.20 Seguridad de la información en los acuerdos con proveedores. No alcanza con confiar en que el proveedor es serio. El contrato tiene que fijar explícitamente los niveles de seguridad exigidos, el derecho a auditar, y qué pasa con la continuidad del servicio si el proveedor sufre un incidente.
- A.5.22 Seguimiento, revisión y gestión de cambios de los servicios de proveedores. Evaluar a un proveedor una vez, al firmar el contrato, no sirve de nada tres años después. Hay que revisar periódicamente si ese proveedor subcontrató nuevos servicios o cambió de infraestructura sin avisar.
- A.5.23 Seguridad de la información para el uso de servicios en la nube. Este es, probablemente, el control más relevante del caso: exige definir criterios claros para la adquisición, el uso, la gestión y la salida de servicios cloud, incluyendo qué pasa con los datos si el proveedor deja de operar o sufre un ataque como este.
- A.5.30 Preparación de las TIC para la continuidad del negocio. Exige que la organización tenga, probado y no solo documentado, un plan para seguir operando si su infraestructura tecnológica (propia o de terceros) deja de estar disponible por horas o días.
El patrón que conecta estos cinco controles es el mismo que falló en el caso japonés: ninguna de las empresas afectadas por la vía del correo o la bodega controlaba directamente la infraestructura que cayó, pero todas dependían de ella. Un SGSI que solo evalúa al proveedor con el que se firmó el contrato, sin preguntar sobre qué corre ese proveedor, deja exactamente ese punto ciego.
Qué exige ISO 28000 frente al eslabón físico de la cadena
Cuando la falla digital ya ocurrió, lo que decide si una empresa de logística como Nissui sigue operando o se detiene por completo es la robustez de su plan de continuidad bajo ISO 28000:2022. La norma exige evaluar el riesgo de seguridad de toda la cadena de suministro, incluyendo a los subcontratistas de almacenamiento, transporte y tecnología, y traducir eso en planes de contingencia probados (no solo firmados) para el escenario en que un eslabón tecnológico de la cadena deja de funcionar sin aviso. Eso incluye preguntas muy concretas: si el sistema que gestiona las recepciones y despachos de la bodega depende de un proveedor cloud, ¿existe un procedimiento manual de respaldo para seguir despachando mercadería mientras se restablece el sistema? ¿Se sabe, con precisión, cuántos proveedores de la cadena (de transporte, de almacenamiento, de tecnología) dependen a su vez del mismo centro de datos, concentrando sin querer todo el riesgo en un solo punto?
Por qué separar las dos normas ya no alcanza
El caso de Japón no es una anécdota aislada. El informe «Ransomware bajo presión» de Google Threat Intelligence Group, publicado en marzo de 2026, encontró que la infraestructura de virtualización fue objetivo en aproximadamente el 43% de las intrusiones de ransomware que investigó en 2025, frente a un 29% el año anterior. Es decir: atacar la capa de virtualización en la que corren decenas o cientos de clientes a la vez, en lugar de atacar a una sola empresa, es una tendencia creciente y deliberada, porque multiplica el daño por cada minuto de trabajo del atacante.
Frente a esa tendencia, gestionar la seguridad de la información y la seguridad de la cadena de suministro como dos proyectos separados, con dos matrices de riesgo que no se cruzan, deja exactamente el punto ciego que exploitó este ataque: nadie en la empresa de logística sabía que su sistema de despacho corría sobre la misma infraestructura que el sistema de correo de una empresa ferroviaria al otro lado del país, y nadie en el equipo de seguridad de la información tenía mapeado qué pasaba en la bodega si esa infraestructura fallaba. Un mapa de riesgo único, que cruce los activos de información (cuentas, bases de datos, sistemas en la nube) con los activos físicos y operacionales de la cadena de suministro (bodegas, transporte, subcontratistas), es la única forma de ver ambos lados del mismo incidente antes de que ocurra.
Qué hacer ahora
Primero, pedir a cada proveedor crítico (no solo a los proveedores cloud evidentes, sino también a los servicios de email, facturación o gestión de despachos) sobre qué infraestructura corre su servicio, y si esa infraestructura está compartida con otros clientes de la empresa. Segundo, incorporar explícitamente en el análisis de riesgo del SGSI la pregunta de «cuarta parte»: no solo quién es el proveedor directo, sino quién sostiene a ese proveedor. Tercero, para empresas de logística o cadena de suministro certificadas en ISO 28000, probar (no solo documentar) el procedimiento manual de respaldo para seguir despachando o recibiendo mercadería si el sistema tecnológico que gestiona esas operaciones queda inaccesible por horas. Cuarto, revisar si distintos proveedores críticos de la empresa concentran, sin que nadie lo haya planificado, su infraestructura en el mismo centro de datos o la misma nube, porque esa concentración es exactamente lo que transformó un ataque de siete minutos en una caída que afectó a 495 organizaciones a la vez.
¿Tu empresa sabe hoy sobre qué infraestructura corren sus proveedores críticos, más allá del contrato que firmaron con ellos?
En Profile Empresarial te ayudamos a construir un mapa de riesgo integrado bajo ISO 27001 e ISO 28000, que cruce la seguridad de la información con la seguridad de la cadena de suministro antes de que un incidente como el de Japón te obligue a hacerlo de urgencia. Agenda tu diagnóstico con nuestro equipo.
Profile Empresarial. Tu Certificación, Nuestro Compromiso.