CISA lanza una alerta incómoda para Fortinet: 74.000 dispositivos expuestos y una vieja lección sobre credenciales

Cuando una agencia como CISA sale a pedir medidas inmediatas sobre un fabricante concreto, no suele ser por deporte. Esta vez el aviso apunta a dispositivos Fortinet expuestos a internet —sobre todo FortiGate y pasarelas SSL VPN— tras informes de credenciales comprometidas asociadas a aproximadamente 74.000 equipos. El nombre informal de la campaña, FortiBleed, suena a branding de ciberamenaza de 2026. El problema, por desgracia, es bastante menos glamuroso: credenciales reutilizadas, accesos administrativos accesibles desde fuera, sesiones activas que nadie ha matado y una dependencia persistente de VPNs y firewalls como si fueran solo cajas de red, cuando en realidad son identidades privilegiadas con carcasa.

La alerta de CISA del 18 de junio de 2026 no describe una vulnerabilidad concreta con CVE propio en ese texto, y eso importa. No estamos ante el patrón clásico de “parchea esta versión antes de medianoche”. Estamos ante algo peor para muchos equipos: una intrusión potencialmente habilitada por credenciales expuestas o comprometidas, donde el parche por sí solo no limpia el problema. CISA ha sido bastante explícita con las prioridades: terminar sesiones activas, resetear credenciales VPN y administrativas, revisar el almacenamiento de credenciales —incluido el uso de PBKDF2 en FortiOS 7.2.11 y posteriores—, revisar logs para detectar movimiento lateral, imponer MFA resistente al phishing y, sobre todo, sacar la administración del firewall de internet pública.

Traducido al castellano operativo: si tu organización tiene FortiGate accesible desde internet y no ha revisado ya sesiones, cuentas y hashes, no tienes un problema teórico. Tienes una hipótesis de compromiso hasta que demuestres lo contrario.

Lo relevante de la alerta no es solo el número. Es el tipo de fallo que deja al descubierto

Las cifras que se citan alrededor del caso bailan un poco según la fuente. CISA habla de aproximadamente 74.000 dispositivos. Otras fuentes enlazadas por la propia agencia, como SOCRadar o Hudson Rock, elevan la estimación a 75.000 u 80.000, y Arctic Wolf sitúa el alcance geográfico en 194 países. Esa variación no cambia lo esencial: estamos hablando de una huella global, internet-facing, y de un fabricante con una base instalada enorme en empresas y administraciones.

Lo interesante aquí es que CISA no se limita a decir “actualice”. Insiste en cinco acciones concretas y todas apuntan a la misma conclusión: el riesgo no termina cuando aplicas una versión nueva, porque el atacante puede haber entrado ya. Por eso pide cerrar todas las sesiones SSL VPN y administrativas activas. Por eso exige resetear credenciales, especialmente en sistemas expuestos a internet. Por eso habla de revisar logs de firewall, VPN, autenticación y controladores de dominio para buscar movimiento lateral, cuentas sospechosas o cambios no autorizados de configuración. Y por eso insiste en MFA resistente al phishing, no en cualquier MFA cosmético que se derrota con un reverse proxy bien montado.

Ese matiz separa una incidencia técnica de una crisis de acceso privilegiado. Si las credenciales de administración o de acceso remoto han quedado expuestas, el perímetro deja de ser perímetro. El firewall pasa de ser un control de seguridad a ser un punto de apoyo del adversario. Y cuando eso ocurre, las organizaciones que siguen tratando los appliances de red como “infraestructura” en lugar de “sistemas críticos con identidad propia” descubren de golpe que llevaban años auditando lo equivocado.

Por qué Fortinet vuelve a estar en el foco: no solo por el producto, también por su posición en la arquitectura

Fortinet no aparece en las alertas por una cuestión de mala suerte estadística. Sus dispositivos ocupan un lugar muy sensible en la arquitectura de muchas empresas: terminan VPNs, administran accesos remotos, filtran tráfico, aplican políticas y, en muchos entornos medianos, concentran una cantidad absurda de privilegio operativo. Un fallo en ese punto no se parece al compromiso de una estación de trabajo. Se parece más a darle al atacante un mapa, una llave maestra y una sala de control.

Además, los appliances de red han heredado un pecado histórico del sector: durante años se desplegaron con la prioridad puesta en la disponibilidad y la conectividad, no en la higiene de identidad. Interfaz de administración abierta “temporalmente”, acceso desde cualquier origen porque “lo necesita el proveedor”, cuentas locales que sobreviven a tres CISOs y dos adquisiciones, contraseñas que se cambian solo tras un incidente, y MFA que se considera opcional para administradores porque “complica el soporte”. Luego llegan los comunicados de urgencia y todo el mundo finge sorpresa.

No ayuda que Fortinet arrastre un historial que ha obligado en varias ocasiones a revisar exposición de gestión, acceso VPN y prácticas de hardening. En 2024, por ejemplo, CISA añadió varias vulnerabilidades de Fortinet a su catálogo de vulnerabilidades explotadas conocidas, el famoso KEV, que es donde un problema deja de ser una diapositiva para convertirse en evidencia de explotación real. Ese contexto pesa porque explica por qué los atacantes siguen mirando a esta superficie: la recompensa es alta, la ubicación es estratégica y la base instalada, masiva.

También hay una ironía menos divertida. En muchas compañías se ha invertido bastante en EDR, SOAR, telemetría cloud y detección basada en comportamiento, mientras que la administración de dispositivos perimetrales sigue dependiendo de accesos heredados y prácticas casi artesanales. Mucha sofisticación en PowerPoint; poca disciplina en los bordes de la red. CISA, esta vez, no está descubriendo un continente. Está recordando algo que se supone que ya sabíamos.

Qué ha pedido exactamente CISA y por qué cada punto cambia la respuesta al incidente

La lista de CISA merece leerse como una secuencia de contención y no como una simple colección de consejos.

1. Terminar sesiones y resetear credenciales

Este es el primer movimiento porque una sesión activa comprometida puede sobrevivir a decisiones a medias. Si el atacante mantiene una sesión SSL VPN o administrativa, cambiar una política o incluso una contraseña aislada puede llegar tarde. CISA pide terminar todas las sesiones activas y resetear contraseñas administrativas y de VPN, con especial atención a sistemas expuestos a internet. Operativamente, eso obliga a coordinar red, IAM, SOC y soporte. No es agradable, pero es bastante más agradable que descubrir una semana después una cuenta persistente o una regla de firewall alterada.

La parte incómoda es esta: muchas organizaciones no tienen inventario claro de qué cuentas administrativas locales siguen vivas en Fortinet, quién las usa realmente y si esas credenciales están federadas, sincronizadas o completamente huérfanas. En un incidente así, esa falta de gobierno se paga en horas.

2. Verificar el almacenamiento seguro de credenciales

CISA cita expresamente el uso de PBKDF2 para almacenar credenciales de administrador y remite a la guía de Fortinet sobre su aplicación en FortiOS v7.2.11 y posteriores. Aquí no se trata solo de “usar un hash mejor” como quien cambia de champú. PBKDF2 introduce derivación de clave endurecida frente a almacenamiento heredado más débil, lo que eleva el coste de explotación si las credenciales o sus derivados quedan expuestos.

El detalle técnico importa porque desmonta una excusa frecuente: “ya hemos cambiado las contraseñas”. Si el sistema sigue permitiendo o arrastrando hashes legacy más débiles, el riesgo residual continúa. Hay que verificar la configuración real, no la intención. Y no, un ticket cerrado no es un control técnico.

3. Revisar logs con un objetivo muy concreto

CISA no habla de “monitorizar” en abstracto. Pide revisar logs de firewall, VPN, autenticación y controladores de dominio para buscar movimiento lateral, accesos inusuales, cuentas sospechosas y cambios de configuración no autorizados. Eso da una pista clara: el riesgo no está solo en el dispositivo Fortinet; está en lo que pudo ocurrir después.

Quien tenga FortiGate integrado con Active Directory, LDAP, RADIUS o servicios de identidad centralizados debe asumir que el compromiso potencial puede haber servido para ampliar privilegios, crear persistencia o pivotar hacia servidores internos. Los indicadores a buscar incluyen inicios de sesión administrativos fuera de horario o desde IPs anómalas, creación de nuevos usuarios locales, cambios en políticas NAT o ACL, nuevas configuraciones de túneles, modificaciones en reglas de acceso de gestión y autenticaciones remotas que no encajan con los patrones habituales de negocio.

Si tu SOC no conserva suficiente retención de logs del appliance, de la VPN y del directorio, el incidente te recordará de forma bastante cara que la retención no era un capricho de auditoría. Era capacidad forense mínima.

4. Activar MFA resistente al phishing

CISA podría haber dicho simplemente “habilite MFA”. No lo hace. Exige MFA resistente al phishing para acceso remoto y cuentas administrativas. La diferencia es crítica. SMS, OTP por app o notificaciones push mal configuradas reducen riesgo, sí, pero siguen siendo vulnerables a fatiga de MFA, intermediarios de autenticación o ingeniería social. La referencia práctica aquí son FIDO2, WebAuthn o mecanismos equivalentes con resistencia criptográfica al phishing.

Esto afecta de lleno a proveedores, administradores de red, equipos de soporte y terceros con acceso remoto. Si esos accesos siguen dependiendo de usuario y contraseña reforzados con factores fáciles de secuestrar, el riesgo no desaparece. Se maquilla. Y el maquillaje en ciberseguridad dura hasta el siguiente titular.

5. Reducir la superficie de ataque y cerrar la gestión pública

La recomendación de sacar la administración del firewall de internet pública es probablemente la más elemental y, a la vez, una de las menos cumplidas. CISA pide restringir interfaces de gestión a redes internas de confianza y eliminar cuentas no autorizadas o innecesarias. Parece obvio. No lo es tanto en entornos con soporte remoto, MSPs, integradores, equipos distribuidos o despliegues heredados.

Aquí el criterio debería ser brutalmente simple: si la administración de FortiGate es accesible desde internet abierta, tienes que justificarlo como una excepción temporal y compensada. No como la configuración por defecto de facto. Lo razonable es gestión a través de una red interna, una VPN administrativa segregada o un bastión endurecido, con MFA resistente al phishing y registros completos.

El detalle de PBKDF2 no es menor: habla de una batalla más vieja entre criptografía y deuda heredada

Hay un motivo por el que CISA destaca la necesidad de confirmar el uso de PBKDF2 en el almacenamiento de credenciales administrativas de Fortinet. Cuando una agencia mete un detalle de este nivel en una alerta breve, no es decoración. Está señalando que la calidad del almacenamiento de credenciales forma parte del problema operativo.

PBKDF2, bien implementado, dificulta los ataques de fuerza bruta y cracking offline porque incrementa el coste computacional de probar contraseñas derivadas. En entornos empresariales no resuelve por sí solo la exposición de credenciales, desde luego, pero reduce el impacto de determinadas filtraciones y obliga al atacante a invertir más recursos. Eso importa especialmente cuando el material expuesto puede incluir hashes o representaciones reutilizables.

Lo que deja en mal lugar a muchas organizaciones es otra cosa: la coexistencia entre mecanismos modernos y configuraciones legacy. Ese es el clásico residuo técnico que nadie quiere tocar porque “todo funciona”. Hasta que deja de funcionar para el defensor y empieza a funcionar para el atacante. Si el hardening del fabricante ya contempla migrar a PBKDF2 en FortiOS 7.2.11 y posteriores, la pregunta no es si suena razonable. La pregunta es por qué sigue habiendo despliegues operativos que no han verificado ese cambio o siguen arrastrando cuentas antiguas sin revisar el método de hash.

En otras palabras: no es solo una cuestión de parcheo, sino de higiene criptográfica aplicada a identidades administrativas. Algo bastante menos vistoso que comprar otra consola de detección, pero mucho más útil el día que alguien llama desde el SOC a las tres de la mañana.

Qué deberían hacer ahora los CISOs y responsables de infraestructura, sin teatro y sin esperar al siguiente advisory

La respuesta inmediata no consiste en reenviar la alerta de CISA con un “por favor revisar”. Eso sirve para cubrir expediente interno, no para reducir exposición. Si tienes dispositivos Fortinet accesibles desde internet, la secuencia razonable arranca por confirmar inventario real: modelos, versiones de FortiOS, funciones activas, interfaces de gestión expuestas, uso de SSL VPN y dependencia de cuentas locales frente a identidades centralizadas.

Después viene la parte menos glamurosa y más eficaz: cerrar sesiones, rotar credenciales, verificar MFA resistente al phishing, revisar si la gestión pública sigue abierta y comprobar la configuración de almacenamiento de credenciales conforme a la guía de Fortinet para PBKDF2. El orden importa porque un análisis forense sin contención puede dejar al atacante observando cómo le buscas.

En paralelo, hay que elevar la profundidad de la revisión de logs. No basta con mirar el propio appliance. Revisa correlaciones con directorio, SIEM, saltos a servidores internos, nuevas conexiones administrativas, cambios en políticas y cualquier comportamiento que sugiera movimiento lateral. Si el firewall fue el punto de entrada, la pregunta ya no es “si entraron”, sino “hasta dónde pudieron llegar”.

Otra prioridad: terceros. Muchas instalaciones de Fortinet son administradas o coadministradas por integradores, MSSPs o proveedores de conectividad. Eso implica revisar cuentas de proveedor, origen de accesos, privilegios concedidos, bastiones usados y necesidad real de cada permiso. Es el momento ideal para descubrir que una cuenta genérica de soporte creada en 2022 sigue viva y no tenía MFA. Ideal para descubrirlo ahora; bastante menos ideal en un informe post-incidente.

Y sí, conviene preparar comunicación interna. No para dramatizar, sino para gestionar impacto operativo. Cerrar sesiones SSL VPN, resetear credenciales y cambiar rutas de administración puede interrumpir negocio. Mejor una interrupción controlada que una persistencia silenciosa. Las organizaciones que intentan resolver esto sin molestar a nadie suelen acabar molestando a todo el mundo durante bastante más tiempo.

El ángulo regulatorio europeo: DORA, NIS2 y GDPR convierten un advisory técnico en un asunto de gobernanza

Aunque la alerta de CISA es estadounidense y la noticia se mueve en el terreno de la ciberseguridad operativa, en Europa esto ya no es “solo un tema del equipo de red”. Para entidades financieras sujetas a DORA, para organizaciones cubiertas por NIS2 y para cualquier compañía que procese datos personales relevantes, el episodio encaja de lleno en obligaciones de gestión del riesgo, notificación y control de terceros.

Empecemos por DORA, aplicable desde el 17 de enero de 2025 a una lista amplia de entidades financieras de la UE. El Reglamento (UE) 2022/2554 exige un marco de gestión del riesgo de las TIC robusto. El artículo 6 obliga a contar con un marco interno sólido y documentado para todos los riesgos TIC. El artículo 8 entra en protección y prevención, incluyendo políticas, procedimientos, protocolos y herramientas para salvaguardar sistemas TIC y organizar la respuesta. El artículo 10 aborda detección. El 11, respuesta y recuperación. Si un banco, aseguradora o firma de inversión mantiene interfaces de gestión de firewalls accesibles desde internet sin MFA fuerte o con cuentas locales heredadas, no estamos hablando de una observación técnica menor. Estamos hablando de un posible fallo de control en el corazón del marco de resiliencia operacional.

DORA también aprieta donde más duele a los equipos acostumbrados a externalizar: terceros TIC. Los artículos 28 a 30 exigen gestionar el riesgo derivado de proveedores TIC con criterios contractuales, de monitorización y salida. Si un MSSP o integrador administra Fortinet en tu nombre, no basta con decir que “lo lleva el proveedor”. Eso, ante un supervisor, no es una estrategia; es una coartada débil.

NIS2, por su parte, eleva el listón de ciberseguridad y gobernanza para entidades esenciales e importantes. El artículo 21 exige medidas técnicas, operativas y organizativas apropiadas y proporcionadas, incluyendo gestión de incidentes, seguridad de la cadena de suministro, higiene cibernética y formación, seguridad en adquisición, desarrollo y mantenimiento, y uso de autenticación multifactor o soluciones de autenticación segura cuando proceda. Un incidente o riesgo material ligado a credenciales comprometidas en pasarelas VPN encaja de forma bastante directa en ese mapa. Además, NIS2 endurece la responsabilidad de la dirección: el artículo 20 habla del papel de los órganos de dirección en la aprobación y supervisión de medidas de gestión de riesgos. Dicho de otro modo: si el acceso administrativo a un firewall crítico seguía abierto a internet y sin controles sólidos, ya no es solo un problema del administrador de red. Es un problema de gobernanza.

Y luego está GDPR. No toda exposición de credenciales desencadena una brecha de datos personales notificable, pero muchas sí pueden conducir a accesos no autorizados a sistemas que contienen datos personales. Si hay violación de seguridad de los datos personales, el artículo 33 del RGPD obliga a notificar a la autoridad de control sin dilación indebida y, de ser posible, en un plazo máximo de 72 horas desde que el responsable tenga constancia. El artículo 34 añade la comunicación a los interesados cuando sea probable un alto riesgo para sus derechos y libertades. La dificultad práctica no es jurídica; es temporal. Si la organización no puede determinar con rapidez si hubo acceso a sistemas con datos personales porque no tiene logs suficientes del firewall, VPN y directorio, la capacidad de cumplir el plazo de 72 horas se degrada enseguida.

La combinación es bastante clara: CISA emite un aviso técnico, pero en Europa la lectura madura es de gobierno de accesos privilegiados, evidencia de controles, terceros TIC y preparación de notificación.

Lo que esta alerta revela sobre la dependencia enferma de SSL VPN

La industria lleva años intentando salir de la dependencia excesiva de SSL VPN para acceso remoto de usuarios, administradores y terceros. Y, sin embargo, cada cierto tiempo una alerta como esta recuerda que seguimos construyendo demasiado sobre ese punto de concentración. Las VPN no son el demonio, pero sí un objetivo tentador: están expuestas, autentican identidades, abren camino hacia dentro y suelen convivir con excepciones acumuladas durante años.

El movimiento hacia arquitecturas de acceso de confianza cero, acceso a aplicaciones con identidad fuerte, segmentación y bastiones administrados no es una moda de arquitectos aburridos. Es la respuesta a un problema recurrente: cuando el acceso remoto depende de pocos nodos muy privilegiados, cualquier fuga de credenciales o explotación allí multiplica el radio de impacto. La alerta de CISA no obliga a rediseñar la arquitectura mañana, pero sí deja una pregunta que conviene hacerse sin autoengaño: ¿tu organización usa SSL VPN porque es la mejor opción para cada caso de uso, o porque nadie ha querido desmontar la solución heredada?

En entornos regulados, esa pregunta ya no es filosófica. Bajo DORA y NIS2, la capacidad de justificar decisiones de arquitectura con base en riesgo y proporcionalidad gana peso frente al tradicional “siempre lo hemos hecho así”. Siempre se ha hecho así es un argumento magnífico, salvo cuando toca explicárselo a un supervisor o a un comité de crisis.

La gestión de terceros puede ser el verdadero agujero, no el dispositivo en sí

Hay otro ángulo que muchas empresas subestiman hasta que llega una alerta de este tipo: quién administra realmente los dispositivos perimetrales y cómo lo hace. En no pocos entornos, FortiGate lo toca el equipo interno, el integrador, el proveedor de telecomunicaciones, el MSSP y a veces un contratista puntual. Es decir, lo toca medio mundo, y nadie tiene una fotografía perfecta de qué cuenta corresponde a quién, con qué permisos y desde qué origen.

Ese desorden no es solo una mala práctica. Bajo DORA, el riesgo de terceros TIC exige inventario, clasificación, monitorización y condiciones contractuales concretas. Bajo NIS2, la cadena de suministro y las relaciones con proveedores son parte explícita de las medidas del artículo 21. En el plano operativo, eso se traduce en preguntas bastante menos abstractas: ¿las cuentas de proveedor están nominativas o son genéricas? ¿Usan MFA resistente al phishing? ¿Acceden desde IPs restringidas o desde cualquier lugar del planeta? ¿Se registran sus acciones de administración? ¿Existe revisión periódica de necesidad y privilegio? ¿La salida contractual contempla revocación inmediata y recuperación de control?

Una exposición de credenciales en dispositivos perimetrales convierte esas preguntas en urgentes. Y deja al descubierto algo incómodo: muchas organizaciones exigen controles férreos a sus usuarios internos mientras toleran accesos administrativos de terceros con un nivel de disciplina claramente peor. Luego los comités se sorprenden de que el mayor riesgo no viniera por el empleado de oficina, sino por una cuenta técnica que nadie quiso incomodar.

Qué evidencia técnica conviene preservar si sospechas impacto

Si hay sospecha razonable de compromiso o uso indebido de credenciales, preservar evidencia es tan importante como contener. No porque vaya a quedar bonito en auditoría, sino porque sin esa evidencia la organización se queda ciega para determinar alcance, cronología y obligaciones regulatorias.

Conviene retener de inmediato, con procedimientos que mantengan integridad, los logs del propio FortiGate o de la pasarela SSL VPN, registros de autenticación locales y centralizados, eventos del controlador de dominio o del IdP, cambios de configuración, altas y bajas de cuentas, sesiones administrativas, conexiones entrantes a interfaces de gestión, y cualquier telemetría de red o EDR que permita correlacionar actividad posterior al acceso. También interesa capturar configuración actual y diferencias respecto a baselines aprobados: reglas de firewall, objetos, políticas, túneles, certificados y administradores configurados.

La razón es simple. En estos casos, la pregunta crítica casi nunca es si había exposición pública del dispositivo; eso se comprueba rápido. La pregunta difícil es si esa exposición se materializó en acceso no autorizado y, de ser así, qué tocó el atacante después. Sin una línea temporal fiable, la organización no puede decidir con seguridad si activa un proceso de notificación, si reemite credenciales más allá del perímetro o si debe tratar el caso como incidente de cadena de suministro por acceso de proveedor.

No todas las empresas tienen el mismo riesgo, pero casi todas comparten las mismas malas costumbres

La exposición no impacta igual a una pyme con una única VPN que a una entidad multinacional con decenas de firewalls, múltiples dominios, terceros conectados y administración distribuida. El riesgo también cambia según si FortiGate se usa solo para filtrado, para SSL VPN, para SD-WAN o para funciones mixtas. Y no es lo mismo tener interfaces de gestión totalmente internas que mantenerlas accesibles desde internet con restricciones parciales.

Ahora bien, hay patrones de riesgo que se repiten con una tozudez admirable. Cuentas locales administrativas que sobreviven a cualquier programa IAM. Gestión remota abierta “porque si no el proveedor no puede entrar”. MFA parcial, aplicado a usuarios pero no a administradores. Logs del firewall reenviados sin suficiente detalle o con retención mínima. Falta de reconciliación entre inventario CMDB y configuración real del perímetro. Y una dependencia casi supersticiosa de que el fabricante avisará siempre con tiempo suficiente. No funciona así.

La lectura correcta de la alerta de CISA no es “Fortinet tiene un problema”. Es “la gestión de credenciales y administración de dispositivos perimetrales sigue siendo endeble en demasiadas organizaciones”. Fortinet es el vehículo del episodio. La enfermedad es más amplia.

Perspectiva: esta vez CISA no está exagerando

A veces los reguladores y agencias emiten recomendaciones tan genéricas que apenas añaden nada a lo que un buen equipo ya sabe. No parece ser el caso. La alerta de CISA del 18 de junio de 2026 tiene un valor claro precisamente porque no se queda en la frase habitual de parchear y vigilar. Señala un patrón de compromiso basado en credenciales, da una magnitud aproximada —74.000 dispositivos—, enumera acciones inmediatas concretas y remite a un punto técnico delicado: el almacenamiento de credenciales con PBKDF2 en FortiOS 7.2.11 y posteriores.

Eso no resuelve todas las incógnitas. La cifra exacta puede variar según las fuentes. El alcance real por organización dependerá de cómo estuviera configurado cada entorno, de qué servicios estaban expuestos y de si hubo o no actividad posterior. Pero el mensaje central no tiene demasiada ambigüedad: si administras Fortinet expuesto a internet y no has actuado ya sobre sesiones, credenciales, MFA, logs y acceso de gestión, vas tarde.

Y aquí está la lección que trasciende el titular. El sector lleva años hablando de resiliencia, identidad, zero trust y gobierno de terceros. Muy bien. Luego una alerta de CISA obliga a recordar que aún hay firewalls gestionados desde internet, con cuentas heredadas y controles desiguales. La ciberseguridad moderna tiene una capacidad asombrosa para reinventar el vocabulario mientras conserva vicios bastante antiguos.

La buena noticia es que este tipo de exposición sí permite una respuesta concreta. Inventario real. Cierre de sesiones. Rotación de credenciales. Verificación de PBKDF2 donde aplique. MFA resistente al phishing. Revisión forense de logs y cambios. Restricción severa de la administración. Revisión de cuentas de terceros. Si la organización hace eso con disciplina, la alerta puede quedarse en susto y en trabajo incómodo de fin de semana. Si no lo hace, el siguiente comunicado quizá ya no llegue de CISA, sino del regulador, del CERT nacional o del despacho que redacta la notificación de brecha.