Las cinco lecciones anteriores han construido el arsenal completo del módulo: el mapa de la disciplina, el catálogo de ataques técnicos, la ingeniería social, las medidas de protección y el control de acceso. Ahora toca la prueba de realidad. Esta lección analiza incidentes que ocurrieron de verdad, son públicos y están documentados, y los somete a un método de análisis reproducible. No los estudiamos por morbo ni por su tamaño: los estudiamos porque en todos ellos fallaron controles que ya conoces, y porque las mismas causas se repiten con una regularidad que resulta casi cómica —hasta que le toca a tu empresa—. Verás Target, WannaCry, Equifax, SolarWinds, Colonial Pipeline y un caso de almacenamiento en la nube mal configurado; para cada uno, una tabla de fallo de control, control que lo habría evitado y lección aplicable a Nimbus. Y cerraremos con una reconstrucción hora a hora de un incidente ficticio pero plausible en Nimbus Reservas, para responder a la única pregunta que importa: qué habría cambiado el desenlace.

1. El método: cómo se analiza un incidente
2. Target (2013): el proveedor como puerta de entrada
3. WannaCry (2017): la vulnerabilidad conocida y sin parchear
4. Equifax (2017): parche pendiente y detección ciega
5. SolarWinds (2020): la cadena de suministro y la firma de código
6. Colonial Pipeline (2021): una VPN sin MFA y una decisión de pago
7. Fuga por almacenamiento en la nube mal configurado
8. Los patrones que se repiten en todos
9. Caso Nimbus: reconstrucción hora a hora de un ransomware
10. Cierre del módulo

Sin método, el análisis de un incidente degenera en anécdota («les entró un virus») o en juicio moral («fueron unos descuidados»). Ninguna de las dos cosas mejora la seguridad de nadie. El método siguiente tiene seis pasos y se aplica igual a un caso público que a un incidente propio.

Tres reglas que hacen que el análisis sea útil:

1. Buscar causas, no culpables. Casi nunca hay un villano. Hay un administrador con 400 alertas al día, un plazo de entrega imposible o un procedimiento que nadie revisó en tres años. Un análisis que termina señalando a una persona garantiza que la próxima vez nadie informe de nada —exactamente la regla cultural de 02-03.
2. Distinguir el fallo técnico del fallo organizativo. En casi todos los casos que siguen, el control técnico existía. Lo que falló fue el proceso alrededor: quién mira la alerta, quién aplica el parche, quién revisa el certificado. Los incidentes grandes rara vez son problemas técnicos difíciles.
3. Preguntar siempre «¿nos pasaría a nosotros?» con honestidad. El reflejo natural es pensar «eso fue porque eran enormes y descuidados». Casi siempre, la traducción a una PYME es directa y más fácil de explotar.

Nota: los casos siguientes se basan en información pública —informes oficiales, comparecencias, publicaciones de investigadores y comunicados de las propias empresas—. Las cifras y fechas son las comúnmente aceptadas, pero cualquier análisis de un incidente real ajeno debe tomarse con la prudencia de que la información completa rara vez es pública. El objetivo aquí es didáctico, no forense ni acusatorio.

• Vector inicial: credenciales de un proveedor externo (servicios de climatización) que tenía acceso a la red corporativa para tareas de facturación y monitorización remota.
• Movimiento: desde ese acceso se alcanzó la red donde operaban los terminales de venta. La red no estaba adecuadamente segmentada: un proveedor de aire acondicionado no debería poder alcanzar jamás el entorno de pago.
• Impacto: decenas de millones de registros de tarjetas y de datos personales; costes directos e indirectos de cientos de millones; dimisión del director ejecutivo y del responsable de sistemas.

El dato que convierte a Target en el caso más citado de la historia de la seguridad corporativa: las herramientas funcionaron. Detectaron la actividad maliciosa y avisaron. El fallo no fue de tecnología, fue de proceso: nadie con capacidad de decisión atendió esas alertas a tiempo. Es la ilustración perfecta del desequilibrio del NIST CSF que diagnosticaste en 02-01: mucho Proteger, poco Detectar entendido como capacidad organizativa de responder a lo detectado.

• Vector inicial: explotación directa de una vulnerabilidad de SMB en sistemas expuestos o alcanzables desde una red comprometida. El parche llevaba dos meses disponible.
• Movimiento: propagación automática, tipo gusano, sin intervención humana: cada equipo infectado escaneaba y contagiaba a otros. Es lo que explica la velocidad.
• Impacto: paralización de servicios en múltiples países. El caso más documentado es el del sistema público de salud británico: miles de citas y operaciones canceladas, ambulancias desviadas, equipos de diagnóstico inoperativos. El daño no fue el rescate: fue la parada operativa.

La lección incómoda de WannaCry: no hubo ninguna técnica novedosa, ningún 0-day en el momento del ataque, ninguna sofisticación. Fue una vulnerabilidad conocida, con parche disponible, sin aplicar. La medida menos vistosa del catálogo de 02-04 —el parcheo— habría neutralizado el mayor incidente de propagación masiva de la historia reciente.

Y una precisión sobre el kill switch que suele contarse mal: no fue una defensa organizada ni un plan de nadie. Fue un investigador que analizó el código, vio una consulta a un dominio no registrado y lo registró por unos pocos dólares. Frenó esa variante. Confiar la supervivencia de tu empresa a que alguien tenga esa idea a tiempo no es una estrategia.

• Vector inicial: vulnerabilidad crítica conocida y con parche disponible desde hacía dos meses en una aplicación web accesible desde Internet.
• Movimiento: una vez dentro, los atacantes encontraron credenciales almacenadas en claro que les dieron acceso a decenas de bases de datos que no tenían relación con el sistema comprometido inicialmente. Ausencia total de segmentación y de mínimo privilegio.
• La detección ciega: el dispositivo que inspeccionaba el tráfico cifrado de salida necesitaba un certificado válido. Ese certificado llevaba unos diez meses caducado, de modo que la inspección no funcionaba. Los atacantes exfiltraron durante 76 días por un canal que la organización creía estar vigilando.
• Impacto: datos personales sensibles de casi 150 millones de personas; sanciones y acuerdos por cientos de millones; dimisiones en la cúpula.

La lección que hace de Equifax el caso más instructivo de todos: la organización tenía el control de detección. Lo había comprado, instalado y configurado. Pero llevaba diez meses sin funcionar y nadie lo sabía. De ahí la regla que conviene grabar:

Todo control necesita un control que verifique que sigue funcionando. Certificados que caducan, agentes que dejan de reportar, copias que empiezan a fallar, alertas que se desactivaron «temporalmente» hace un año. Una defensa se degrada en silencio, y el silencio se parece mucho a la seguridad.

Aplicación práctica inmediata para Nimbus: una comprobación mensual que responda a cinco preguntas: ¿todos los equipos reportan al EDR?, ¿todas las fuentes de log siguen llegando?, ¿la última copia se completó y se restauró?, ¿algún certificado caduca en menos de 30 días?, ¿las cinco alertas de 02-04 se han disparado alguna vez (si nunca, quizá están rotas)?

• Vector inicial: compromiso del proceso de construcción del fabricante. El código malicioso se insertó antes de la firma, de modo que la actualización salió firmada y verificada por el fabricante legítimo.
• Por qué fue tan difícil de detectar: todos los controles habituales pasaban. El fichero venía del proveedor correcto, por el canal correcto, con la firma correcta. El software se comportaba con normalidad durante semanas antes de activarse, y su tráfico de mando y control imitaba el protocolo legítimo del producto.
• Impacto: acceso a redes de organismos públicos y grandes empresas; un coste de investigación y remediación difícil de cuantificar, y un impacto duradero en la confianza en el modelo de actualizaciones automáticas.

La conclusión honesta, y por eso este caso es especial: frente a un adversario con recursos estatales que compromete la cadena de construcción de un proveedor legítimo, una PYME como Nimbus no tiene defensa preventiva realista. Pretender lo contrario sería deshonesto. Lo que sí puede hacer, y es exactamente el enfoque «asume la brecha» de 01-03:

1. Limitar los privilegios de todo software de terceros. Si una herramienta de monitorización no necesita ser administrador del dominio, que no lo sea.
2. Controlar el tráfico de salida. Un canal de mando y control necesita salir. Un filtrado de salida con lista blanca es la defensa que sí está al alcance.
3. Detectar comportamiento, no solo origen: una herramienta conocida haciendo algo que nunca hacía.
4. Mantener SBOM para poder responder rápido cuando se publique el siguiente caso.
5. Reducir el número de terceros con acceso privilegiado. Cada uno es una cadena de suministro adicional que no controlas.

• Vector inicial: una sola credencial, de una cuenta de VPN antigua que seguía activa, con una contraseña reutilizada aparecida en una brecha ajena, sin segundo factor. Ni exploit, ni 0-day, ni phishing sofisticado.
• Movimiento: desde el acceso a la red corporativa, el atacante exfiltró datos y desplegó ransomware.
• El detalle más instructivo: el sistema industrial que mueve el combustible no fue cifrado. La parada fue una decisión de negocio: al no poder determinar con certeza el alcance del compromiso ni facturar correctamente, se optó por detener la operación. Es decir, el impacto operativo lo causó la incertidumbre, no el cifrado.
• Impacto: desabastecimiento de combustible en la costa este de Estados Unidos, compras de pánico, declaración de emergencia regional.

Sobre la decisión de pagar, que es lo que más se debate y lo que peor se entiende:

• Pagar no restauró el servicio. La herramienta de descifrado entregada era tan lenta que la recuperación real se hizo con las copias propias. Es un resultado frecuente: el descifrado suele ser lento, parcial y poco fiable.
• Pagar no resuelve la exfiltración. Los datos ya habían salido. La segunda extorsión no se cancela con el primer pago.
• Pagar financia el modelo de negocio y marca a la organización como pagadora, lo que aumenta la probabilidad de un nuevo ataque.
• Y aun así, hay situaciones en que una organización sin copias válidas se enfrenta a la desaparición. Por eso la única decisión que se toma antes del incidente, y que hace innecesaria la discusión, es tener copias inmutables probadas.

Nota legal: el pago de rescates tiene implicaciones legales, fiscales, de seguros y de posibles sanciones que varían según la jurisdicción y la identidad del grupo atacante. Ante un caso real, la decisión debe tomarse con asesoría jurídica y en coordinación con las autoridades competentes. Este curso no recomienda pagar; describe el caso con fines formativos.

La lección estructural para Nimbus: una empresa enorme, con presupuesto y con infraestructura crítica, fue detenida por una contraseña reutilizada en una cuenta olvidada. Si el vector es ese, el tamaño y el presupuesto no protegen. Lo que protege es la higiene de identidades, que es gratis.

Este caso no es una empresa concreta: es un patrón que se ha repetido cientos de veces en la última década, en compañías de todos los tamaños. Lo tratamos como caso porque es, con diferencia, el más probable para Nimbus.

• Vector inicial: ninguno. No hay intrusión, no hay explotación, no hay credencial robada. Los datos estaban públicos y alguien los descargó. Técnicamente, ni siquiera es un ataque.
• Por qué se repite tanto: el permiso público resuelve un problema inmediato («no me funciona el acceso») y el coste aparece meses después; la persona que lo configuró suele no ser la que sufre las consecuencias; y no hay ninguna señal de alarma —el bucket funciona perfectamente.
• Impacto típico: exposición completa de los datos contenidos, sin límite ni trazabilidad de quién los descargó. En términos de notificación de brecha, es el peor escenario: hay que asumir el acceso total por parte de desconocidos.

La conexión directa con Nimbus no es hipotética: en el inventario de 01-04 ya apareció la hoja de nóminas de Sara con enlace «cualquiera con el enlace puede ver». Es el mismo fenómeno, en otro servicio y a menor escala. Un enlace público es una publicación: los enlaces se reenvían, se indexan y se filtran.

Y el escenario que debería quitar el sueño: si alguien exporta un volcado de la base de datos de Nimbus para depurar un problema y lo deja en un bucket accesible, la exposición no son unos cuantos correos, son las agendas completas de cuarenta clínicas, con la carga de sensibilidad que ya conoces por la regla del contexto de 01-04.

Nota sobre implicaciones legales: una exposición de este tipo con datos que revelan información de salud activa obligaciones concretas de notificación y de evaluación del riesgo para los afectados, con plazos exigentes. Debe gestionarse con el responsable de cumplimiento y asesoría jurídica; se trata en 06-03 y 04-05.

Ordenados por frecuencia en los seis casos analizados. Ninguno es exótico. Ninguno requiere un producto caro.

Las tres conclusiones transversales:

1. Casi ningún incidente grande empieza con una técnica sofisticada. Empiezan con un parche pendiente, una cuenta olvidada, un proveedor con demasiado acceso o un permiso mal puesto. La sofisticación, cuando aparece, llega después de entrar.
2. En casi todos los casos, el control existía y no funcionó. Target tenía alertas; Equifax tenía inspección de tráfico; Colonial tenía VPN. Lo que faltó fue el proceso que hace que un control siga siendo un control: alguien que mire, alguien que verifique, alguien que renueve.
3. El tiempo hasta la detección es la variable que más determina el daño. 76 días en Equifax, semanas en Target, meses en SolarWinds. La función Detectar del NIST CSF —la más débil de Nimbus según tu propio diagnóstico de 02-01— es la que separa un incidente de una catástrofe.

Ficción, pero construida con los patrones anteriores y con los hallazgos reales del inventario de Nimbus. Es lo que ocurriría si nada de lo que has aprendido en este módulo se aplicara.

• La consultora de sistemas (A-19) tiene acceso remoto administrativo permanente, con cuentas compartidas entre sus técnicos y sin MFA.
• Las copias de seguridad (A-03) están en la misma cuenta cloud (A-05) que producción y son accesibles con las mismas credenciales de administración.
• Existe registro, pero nadie lo revisa. No hay alertas configuradas.
• Nimbus nunca ha probado una restauración completa.

Este es el ejercicio más valioso de todo el módulo: no basta con listar fallos, hay que ordenar cuáles importan.

Las tres conclusiones:

1. Dos controles de coste nulo o bajo —MFA y acceso just-in-time para el tercero— habrían evitado el incidente por completo. No lo habrían mitigado: lo habrían impedido.
2. Dos controles de coste bajo —el secreto en un gestor y las copias inmutables— habrían convertido una catástrofe en un incidente gestionable. Con el secreto protegido, el atacante se queda en un servidor. Con copias inmutables, Nimbus restaura en horas y el rescate pierde toda su palanca.
3. Ninguno de los diez controles requiere comprar un producto de seguridad. Todos están en el plan de 30 y 90 días de 02-04. El incidente no ocurre por falta de presupuesto: ocurre por falta de decisión.

Y el escenario alternativo, para verlo en positivo. Con las medidas de 02-04 y 02-05 aplicadas, la historia sería esta: día 0, 22:14 — intento de acceso con la credencial de la consultora; el MFA falla; se genera una alerta de intento de acceso de tercero fuera de ventana; Lucía la ve a la mañana siguiente, llama a la consultora, descubre su brecha, revoca el acceso y rota las credenciales. Duración total del incidente: una mañana. Impacto: cero.

Has recorrido el conflicto completo: quién ataca, cómo, por dónde, con qué se defiende uno y qué ocurre cuando no se hace. Y los casos reales han cerrado el círculo mostrando que los conceptos del curso no son teoría: son exactamente los controles que faltaron en cada uno de esos titulares.

Errores comunes:

• Leer los casos como historias ajenas. «Eran gigantescos y descuidados» es el mecanismo mental que impide aprender. La traducción a una PYME es directa y casi siempre más fácil de explotar.
• Quedarse en el vector inicial. El vector explica cómo entraron; los fallos de segmentación, privilegio y detección explican por qué el daño fue enorme.
• Buscar culpables. Un análisis que termina en una persona no cambia nada y garantiza que la próxima vez nadie informe.
• Confundir «teníamos el control» con «el control funcionaba». Equifax tenía inspección de tráfico. Llevaba diez meses ciega.
• Creer que un antivirus habría parado WannaCry. Lo habría parado el parche publicado dos meses antes.
• Pensar que pagar el rescate resuelve el incidente. No devuelve los datos exfiltrados, el descifrado suele ser lento y parcial, y marca a la organización como pagadora.
• Tratar la brecha del proveedor como problema del proveedor. Los datos y los clientes son tuyos, y la responsabilidad ante ellos también.
• Analizar un incidente sin producir cambios concretos con dueño y fecha. Es entretenimiento con formato de informe.

Consejos:

• Aplica el método de los seis pasos a cualquier incidente que salga en las noticias. Media hora de análisis vale más que un curso entero de titulares.
• Después de cada caso, hazte la pregunta incómoda: «¿qué control nuestro es hoy el certificado caducado de Equifax?». Suele haber uno.
• Monta la comprobación mensual de salud de controles: agentes que reportan, fuentes de log que llegan, copias completadas, certificados próximos a caducar, alertas que se han disparado alguna vez.
• Cuando analices un incidente propio, escribe la cronología antes que las conclusiones. Las causas emergen solas cuando las horas están puestas en orden.
• Guarda el análisis y revísalo a los seis meses: la mitad de las acciones acordadas suelen seguir pendientes, y saberlo es más útil que suponer lo contrario.
• Practica el ejercicio del apartado 9.5 —qué controles evitan y qué controles mitigan— con cualquier riesgo de tu organización. Es la forma más rápida de priorizar bien.

Una PYME de 50 personas que ofrece un SaaS de gestión documental sufre este incidente:

• 15 de enero: se publica una vulnerabilidad crítica en la librería de procesamiento de documentos que usan. Sale el parche el mismo día.
• 2 de febrero: un atacante explota la vulnerabilidad en el servidor de conversión de documentos, accesible desde Internet.
• 2-20 de febrero: el atacante descubre que ese servidor tiene montada la carpeta de red donde se guardan todos los documentos de los clientes, con permisos de lectura y escritura.
• 20 de febrero: exfiltra 400 GB de documentos.
• 21 de febrero: cifra la carpeta de red y las copias, que estaban en la misma cabina de almacenamiento.
• 21 de febrero: los clientes reportan que no pueden acceder. Se descubre el incidente.
• 22 de febrero: el equipo descubre que el sistema de alertas envía correos a una dirección de un administrador que dejó la empresa hace ocho meses.

Se pide: (a) aplica los seis pasos del método; (b) construye la tabla de fallo de control → control que lo habría evitado; (c) identifica qué patrones del apartado 8 aparecen; (d) indica los dos controles que habrían cambiado el desenlace y justifica por qué esos y no otros; (e) señala el fallo del 22 de febrero y explica a qué caso de esta lección se parece.

Elige Target o Equifax y realiza una traducción completa a Nimbus Reservas.

Se pide:

1. Escribe la cronología del incidente equivalente en Nimbus, con nombres reales del equipo, activos del inventario A-01…A-22 y horas concretas.
2. Identifica qué elementos del entorno actual de Nimbus hacen ese incidente posible hoy.
3. Enumera los controles que lo evitarían, indicando cuáles están ya en el plan de 30/90/180 días de 02-04.
4. Estima el impacto en Nimbus en cuatro dimensiones: operativa, económica, reputacional y regulatoria.
5. Redacta el párrafo de comunicación que Marta enviaría a los clientes en las primeras 24 horas, teniendo en cuenta que aún no se conoce el alcance completo.

Vuelve al caso Nimbus del apartado 9. El atacante estuvo 20 días dentro sin ser detectado.

Se pide: (a) para cada una de las cinco fases del ataque (acceso inicial, reconocimiento, escalada, exfiltración y sabotaje de copias), define una señal detectable y la fuente de log que la contendría; (b) escribe la regla de alerta correspondiente en pseudocódigo o SQL; (c) ordena las cinco alertas por relación entre valor de detección y coste de implantación; (d) para cada alerta, define quién la recibe, en qué canal y qué hace en los primeros 15 minutos; (e) explica por qué es preferible tener estas cinco alertas que cincuenta.

Solución 1

(a) Método de los seis pasos:

1. Cronología: 18 días desde la publicación del parche hasta la explotación; 19 días dentro sin detección; detección por los clientes el día 21 de febrero. Recuperación previsiblemente larga o imposible.
2. Vector inicial: vulnerabilidad crítica conocida, con parche disponible desde el 15 de enero, en un servidor expuesto a Internet.
3. Movimiento: ninguno sofisticado. El servidor de conversión ya tenía montada la carpeta con todos los documentos de todos los clientes, con permisos de lectura y escritura. Un solo salto por diseño defectuoso.
4. Impacto: 400 GB de documentos de clientes exfiltrados; cifrado de datos y copias; parada de servicio; notificación de brecha con alcance amplio; daño reputacional grave para un SaaS cuyo producto es precisamente custodiar documentos.
5. Fallos de control: tabla siguiente.
6. Lecciones: apartado (d).

(b) Fallos de control:

(c) Patrones presentes: 1 (vulnerabilidad conocida sin parchear), 2 (ausencia de segmentación), 5 (detección tardía), 6 (control que falla en silencio), 8 (copias insuficientes) y 10 (el tamaño no protege). Seis de diez, en un incidente de una empresa pequeña.

(d) Los dos controles decisivos:

1. Parcheo en plazo. Habría evitado la entrada por completo. Es el único control de la lista que impide el incidente en lugar de mitigarlo, y por eso va primero.
2. Copias inmutables y separadas. No evita la entrada ni la exfiltración, pero convierte una posible desaparición de la empresa en una interrupción de horas. Es el control que más impacto elimina por euro invertido.

Los demás controles (segmentación, mínimo privilegio, alertas) son igualmente necesarios, pero estos dos son los que cambian el desenlace: el primero evita que ocurra; el segundo evita que sea terminal.

(e) El fallo del 22 de febrero —las alertas enviadas a la dirección de un ex empleado— es exactamente el caso Equifax: un control de detección que existía, estaba pagado y configurado, y llevaba ocho meses sin funcionar sin que nadie lo supiera. La consecuencia es la misma: falsa confianza, que es peor que no tener el control, porque impide buscar alternativas. Y comparte causa raíz con Colonial Pipeline: una identidad que sobrevivió a la baja de su titular. La corrección es doble: alertas dirigidas a un alias de equipo y comprobación mensual de que las alertas llegan de verdad —por ejemplo, disparando una alerta de prueba.

Solución 2 (desarrollo con el caso Target; el de Equifax es análogo)

1. Cronología equivalente en Nimbus:

2. Qué lo hace posible hoy: acceso de la consultora permanente, compartido y sin MFA (A-19); ausencia de segmentación entre la red de administración y la zona de datos; credenciales administrativas en runbooks (A-17); ausencia de alertas atendidas; ausencia de registro de acceso al bucket A-02; y ningún proceso de revisión del acceso de terceros.

3. Controles y su encaje en el plan de 02-04:

4. Impacto estimado en cuatro dimensiones:

• Operativa: el servicio sigue funcionando (no hay cifrado), pero el equipo dedica semanas a la investigación y la respuesta, y se paraliza todo el desarrollo.
• Económica: costes de análisis forense, asesoría jurídica, comunicación, posible sanción y, sobre todo, pérdida de contratos. Para un SaaS B2B, el mayor coste es la no renovación.
• Reputacional: daño directo al activo A-20. Las clínicas confiaron datos de sus pacientes; el problema es de confianza, no de tecnología.
• Regulatoria: brecha de datos personales que revelan información de salud, con obligaciones de notificación a la autoridad y, probablemente, a los afectados. Debe gestionarse con el responsable de cumplimiento y asesoría jurídica (06-03).

5. Comunicación de Marta en las primeras 24 horas:

«Estimado cliente:

El [fecha] detectamos un acceso no autorizado a parte de nuestra infraestructura, originado en credenciales de un proveedor externo con acceso técnico a nuestros sistemas. Hemos revocado ese acceso, aislado los sistemas afectados y activado nuestro procedimiento de respuesta con apoyo de especialistas externos.

Estamos determinando con precisión qué información ha podido verse afectada. Todavía no disponemos del alcance definitivo y no vamos a comunicar estimaciones sin confirmar. Le informaremos de nuevo en un máximo de 72 horas, aunque sea para decirle que la investigación continúa.

Lo que sí podemos confirmar ahora: el servicio permanece operativo; los datos de pago están tokenizados en nuestra pasarela y no se almacenan en nuestros sistemas; y hemos notificado a la autoridad de control conforme a nuestras obligaciones.

Su interlocutor directo para cualquier consulta es [nombre y teléfono]. Lamento profundamente esta situación y le mantendré informado personalmente.

Marta Solves — Directora Técnica, Nimbus Reservas, S.L.»

Las cinco decisiones de esta comunicación: se comunica pronto aunque no se sepa todo; no se minimiza ni se especula; se dice explícitamente qué no se sabe todavía; se compromete un plazo para la siguiente comunicación y se cumple aunque no haya novedades; y se da un interlocutor con nombre. El error más habitual y más caro es esperar a tener toda la información: para cuando llega, el cliente ya se enteró por otro sitio y la confianza está rota. La comunicación de crisis se desarrolla en 04-05.

Solución 3

(a) y (b) Señales, fuentes y reglas:

(c) Orden por valor/coste:

(d) Destinatario y primeros 15 minutos:

(e) Por qué cinco y no cincuenta. Tres razones, y la tercera es la decisiva:

1. Capacidad real. Nimbus tiene una persona con un porcentaje de su tiempo para esto. Cincuenta alertas producen fatiga y, al cabo de tres semanas, todas se ignoran. Es exactamente lo que ocurrió en Target: las alertas existían y nadie actuó.
2. Cobertura por fase, no por técnica. Estas cinco cubren las cinco fases del ataque. Con tener una sola funcionando en cualquiera de ellas, la cadena se rompe. No hace falta cubrir todas las técnicas: hace falta cubrir todos los momentos.
3. Cada alerta debe tener dueño, canal y procedimiento. Escribir esos tres campos para cinco alertas es una tarde de trabajo; para cincuenta, es un proyecto que no se termina. Una alerta sin dueño no es una alerta: es una línea de log con más letras.

La progresión sana es empezar con cinco que funcionen de verdad, y añadir una nueva cada vez que un incidente o un simulacro revele un punto ciego. Eso es el purple team de coste cero de 02-01: la detección crece a partir de lo que realmente ocurre, no de un catálogo teórico.

Has cerrado el módulo con la prueba de realidad. Tienes un método de análisis de seis pasos —cronología, vector inicial, movimiento, impacto, fallos de control y lecciones— con sus tres reglas: buscar causas y no culpables, distinguir el fallo técnico del organizativo y preguntarse siempre con honestidad si nos pasaría a nosotros. Y lo has aplicado a seis incidentes reales cuyas enseñanzas ya forman parte de tu criterio: Target, donde las herramientas detectaron y nadie actuó, y donde un proveedor de climatización llegó al entorno de pago; WannaCry, donde el mayor episodio de propagación masiva de la historia reciente lo habría neutralizado un parche publicado dos meses antes; Equifax, con su parche pendiente, sus credenciales en claro y —sobre todo— su control de detección caducado durante diez meses, del que sale la regla más transferible de la lección: todo control necesita un control que verifique que sigue funcionando; SolarWinds, que enseña que una firma válida acredita el origen y no la ausencia de malicia, y frente al cual la única estrategia honesta para una PYME es limitar privilegios, controlar la salida y detectar comportamiento; Colonial Pipeline, donde una contraseña reutilizada en una cuenta olvidada y sin MFA detuvo una infraestructura crítica, y donde pagar no restauró el servicio; y la fuga por almacenamiento mal configurado, el patrón más probable para Nimbus, en el que ni siquiera hay ataque.

De todos ellos has extraído los diez patrones que se repiten —parcheo, segmentación, identidad débil, terceros con exceso de acceso, detección tardía, controles que fallan en silencio, secretos mal guardados, copias no probadas, crisis improvisada y la constatación de que el tamaño no protege— junto con las tres conclusiones transversales: que casi ningún incidente grande empieza con una técnica sofisticada, que en casi todos el control existía y no funcionó, y que el tiempo hasta la detección es la variable que más determina el daño. Y has reconstruido hora a hora un ransomware en Nimbus que entra por el acceso remoto de la consultora, escala mediante un secreto olvidado en un .env, exfiltra 1,2 TB durante siete días y destruye unas copias que estaban en la misma cuenta que producción; con su análisis completo y, sobre todo, con la respuesta a la pregunta que da sentido a todo el ejercicio: dos controles de coste nulo —MFA y acceso just-in-time para el tercero— lo habrían evitado por completo, y otros dos de coste bajo —el secreto en un gestor y las copias inmutables— habrían convertido la catástrofe en una mañana de trabajo. Ninguno requiere comprar nada.

Repasa ahora, mentalmente, las defensas que has ido acumulando en estas seis lecciones: TLS protegiendo el tránsito, las URLs firmadas de 120 segundos del bucket de adjuntos, la firma HMAC que autentica el webhook de la pasarela, DKIM acreditando el correo de Nimbus, las passkeys de FIDO2 que resisten al phishing porque la clave nunca sale del dispositivo, la firma RS256 del JWT validada con la clave pública del emisor, el cifrado en reposo de la base de datos y de las copias inmutables, la comparación en tiempo constante del código TOTP, la firma de código de las actualizaciones de SolarWinds. Todas ellas —absolutamente todas— descansan sobre el mismo cimiento: la criptografía. Hasta ahora la hemos usado como una caja negra que funciona; a partir de aquí vamos a abrirla.

En el Módulo 3: Criptografía estudiaremos qué hay dentro de esa caja y por qué se puede confiar en ella. Empezaremos por los fundamentos y el vocabulario, recorreremos la criptografía simétrica y la asimétrica con sus papeles complementarios, las funciones hash, el HMAC y el almacenamiento seguro de contraseñas —que es donde por fin se explica cómo debe guardar Nimbus las contraseñas de sus usuarios—, los protocolos que combinan todas esas piezas, como el TLS que llevas seis lecciones dando por supuesto, la gestión de claves, certificados y PKI, que es el problema realmente difícil, y por último las aplicaciones prácticas en un sistema como el de Nimbus. Empezamos por Introducción a la Criptografía (03-01).