En la lección anterior separaste amenaza de vulnerabilidad y viste que su combinación produce riesgo. Ahora toca llenar esas dos casillas de contenido real. Esta lección es un mapa: qué amenazas existen y de dónde vienen, qué familias de software malicioso hay y cómo se diferencian, qué tipos de debilidades vas a encontrarte en un entorno como el de Nimbus Reservas, y —muy importante para el día a día— cómo se leen los identificadores que usa toda la industria para nombrar y priorizar problemas: CWE, CVE y CVSS. Sin este mapa, un boletín de seguridad es ruido; con él, sabrás en treinta segundos si algo debe corregirse esta tarde o el mes que viene.

1. Taxonomía de amenazas por origen
2. Taxonomía de amenazas por objetivo (contra qué propiedad atentan)
3. Familias de malware: tabla comparativa
4. Amenazas internas: el insider malicioso y el negligente
5. Tipos de vulnerabilidades, con ejemplos del entorno de Nimbus
6. El ecosistema de identificadores: CWE, CVE y CVSS
7. Ventana de exposición y vulnerabilidades de día cero
8. La cadena completa: amenaza + vulnerabilidad → riesgo

Clasificar las amenazas por su origen no es un ejercicio académico: cada origen se contrarresta con un tipo de control distinto. No se defiende igual un error de Sara que una inundación en el CPD del proveedor.

Alguien actúa con intención de causar daño o de obtener un beneficio. Es la categoría que más atención recibe, aunque no siempre sea la más frecuente.

En Nimbus: un grupo de ransomware que llega a través de una credencial de la consultora externa; un competidor que intenta obtener la lista de clientes; un atacante oportunista cuyo bot detecta el puerto de PostgreSQL abierto.

Rasgo clave: hay un adversario adaptativo. Si cierras una puerta, prueba otra. Por eso los controles frente a amenazas deliberadas nunca son «de una vez»: requieren detección y respuesta continuas.

Nadie quería hacer daño; alguien se equivocó. Estadísticamente, esta categoría causa una parte enorme de los incidentes reales.

En Nimbus:

• Lucía marca el bucket S3 de adjuntos como público «un momento, para probar» y se le olvida revertirlo.
• Iván sube por error un fichero .env con la cadena de conexión de producción al repositorio.
• Rubén responde a un correo con un CSV adjunto de 400 clientes finales y se equivoca de destinatario en el autocompletado.
• Sara envía la nómina de un empleado a otro por un fallo de plantilla de correo.

Rasgo clave: no se corrige «formando más» solamente. Se corrige haciendo que el error sea difícil de cometer: valores por defecto seguros, confirmaciones para acciones destructivas, escaneo automático de secretos en el repositorio.

El sistema falla por sí mismo, sin actor humano detrás.

En Nimbus: un disco del servidor de base de datos que se degrada y corrompe páginas; una fuga de memoria que reinicia el contenedor de la API bajo carga; un bug en una librería que trunca los campos de texto; la caducidad no advertida del certificado TLS.

Rasgo clave: se contrarrestan con redundancia, monitorización y pruebas, no con controles de acceso.

Incendio, inundación, corte de suministro eléctrico, corte de fibra, temperatura excesiva. Para una empresa cloud como Nimbus estas amenazas se desplazan hacia el proveedor, pero no desaparecen: siguen existiendo para la oficina de Valencia, y siguen existiendo para el proveedor (que puede perder una zona de disponibilidad entera).

En Nimbus: una obra en la calle corta la fibra de la oficina; una caída regional del proveedor cloud deja la API sin servicio durante horas.

Un matiz importante: el impacto no depende del origen. Si Nimbus pierde su base de datos, da igual si fue ransomware, un disco roto o un DROP TABLE accidental: los clientes están igual de parados. Por eso los planes de recuperación (04-06) se diseñan por consecuencia, no por causa.

La segunda forma de clasificar es por la propiedad de la tríada CIA que atacan. Es útil porque conecta directamente con los controles de la lección anterior.

Muchas amenazas atacan varias propiedades a la vez. El ransomware moderno es el ejemplo perfecto: cifra los datos (disponibilidad), los copia antes de cifrarlos para extorsionar con su publicación (confidencialidad) y a veces los altera (integridad). Este modelo de «doble extorsión» es hoy la norma.

Una tercera clasificación que verás en la práctica, complementaria a las dos anteriores, es la de STRIDE —por propiedad violada— que usarás para modelar amenazas en la lección 01-04.

Malware (de malicious software) es el término paraguas para cualquier software cuya función es dañar, espiar o tomar control sin consentimiento. Las categorías no son excluyentes: una pieza real de malware suele ser un troyano que instala un rootkit y despliega un ransomware. Lo que distingue a cada familia es su mecanismo de propagación o su objetivo, no su forma.

Ransomware. No porque Nimbus sea un objetivo elegido, sino porque el ransomware llega casi siempre por caminos genéricos: una credencial reutilizada de la consultora que da soporte remoto, un portátil de alguien en teletrabajo, un adjunto abierto por Sara. Los factores que determinan si una PYME sobrevive a un ransomware son tres y ninguno es un antivirus: copias fuera del alcance del atacante (inmutables u offline), segmentación (que un equipo comprometido no alcance los servidores) y un plan de respuesta ensayado (módulo 4).

Cryptominer en la nube. Es la amenaza más subestimada de una empresa como Nimbus. Si una clave de acceso al proveedor cloud aparece por error en un repositorio público de GitHub, hay bots que la detectan en cuestión de minutos y arrancan decenas de máquinas de cómputo. El primer síntoma no es una alerta de seguridad: es una factura de 14.000 € a final de mes. Y hay un daño extra: si Nimbus no se entera, no sabe qué más hizo esa clave.

Este curso es defensivo. En ningún momento vamos a escribir, compilar ni distribuir malware, ni analizar muestras reales fuera de un entorno controlado. Lo que necesitas saber como profesional es cómo entra, qué hace y cómo se detecta y se contiene. La detección se trata en 05-02 y la contención en 04-05.

Una amenaza interna (insider threat) es la que procede de alguien que ya tiene acceso legítimo: empleados, ex empleados, becarios, contratistas y —muy relevante en Nimbus— la consultora externa con acceso remoto a sistemas.

Son especialmente difíciles porque el atacante no necesita entrar: ya está dentro, sus credenciales son válidas y sus acciones se parecen a su trabajo diario.

Existe además una tercera figura: el insider comprometido. No es malicioso ni negligente de forma relevante: simplemente le han robado las credenciales. Desde el punto de vista del sistema, la actividad del atacante es indistinguible de la de un empleado legítimo — por eso importa tanto la trazabilidad de la lección anterior y la detección de anomalías de comportamiento.

El caso Nimbus a vigilar: la consultora de sistemas tiene acceso remoto con privilegios elevados. Es un insider a efectos prácticos, pero está fuera del control de RRHH: Nimbus no sabe quién trabaja allí, cuándo alguien se va de esa consultora ni si comparten credenciales. El riesgo de terceros se desarrolla en la lección 04-04; anótalo desde ya como una de las tres o cuatro exposiciones mayores de la empresa.

Recuerda la definición: una vulnerabilidad es una debilidad que una amenaza puede aprovechar. A diferencia de la amenaza, está en tu lado y por tanto la puedes cerrar. Se clasifican así:

a) El bucket S3 de adjuntos accesible públicamente (configuración)

Cómo se lee esa salida: el error no dice «no tienes permiso», dice que no existe una configuración de bloqueo de acceso público. Es decir, nada impide que una política o una ACL abran el bucket al mundo. En un bucket que guarda partes médicos escaneados de pacientes de clínicas, esto es una vulnerabilidad crítica. La corrección inmediata:

Los cuatro parámetros cubren dos vías distintas de exposición: las ACL heredadas (los dos primeros) y las políticas de bucket (los dos últimos). Activar solo dos de los cuatro deja la puerta entreabierta.

b) Una dependencia sin actualizar (software)

Cada línea es una vulnerabilidad potencial: estar desactualizado no implica ser vulnerable, pero sí que no te has enterado si lo eres. pyjwt es el más preocupante aquí, porque es la librería que valida los tokens de sesión de la API: un fallo de validación en la librería de tokens equivale a un fallo de autenticación en toda la aplicación. Las herramientas que cruzan estas versiones con bases de vulnerabilidades conocidas se ven en 05-01.

c) El puerto de la base de datos expuesto (diseño/configuración)

Cómo se lee: 0.0.0.0:5432 significa que PostgreSQL escucha en todas las interfaces de red, no solo en la privada. Si el grupo de seguridad del proveedor cloud permitiera entrada en ese puerto desde 0.0.0.0/0, la base de datos de Nimbus estaría escuchando a Internet. Lo correcto sería ver 10.0.2.15:5432 (solo la red interna) o 127.0.0.1:5432 (solo local). El diagnóstico completo requiere mirar dos capas: la del sistema (ss) y la del cortafuegos del proveedor.

Fíjate en un patrón: de las tres vulnerabilidades, dos son de configuración, no de código. En organizaciones como Nimbus, la mayoría de brechas reales no vienen de un fallo exótico en una librería, sino de algo mal configurado, olvidado o abierto «temporalmente». Es una buena noticia: son las más baratas de cerrar.

Cuando llega un aviso de seguridad, viene lleno de siglas. Cada una responde a una pregunta distinta.

Relación en una frase: una CVE es una instancia concreta de una clase de debilidad (CWE) presente en un producto, y su gravedad se expresa con CVSS.

Así es como se lee una ficha (ejemplo ficticio, construido para esta lección sobre un componente hipotético que Nimbus usaría):

Cómo lo interpreta Iván en cinco pasos:

1. ¿Me afecta? Mira el rango de versiones. Si Nimbus usa reservalib 3.2.0, está en el rango: sí afecta. Este paso es imposible sin inventario de dependencias (SBOM), que veremos en 04-04.
2. ¿Qué clase de fallo es? CWE-89, inyección SQL. Eso le dice qué buscar en el código y qué mitigación temporal tiene sentido.
3. ¿Cuán grave? 9.8, crítico. Y el detalle importa más que el número: lo descompone en el siguiente apartado.
4. ¿Se está explotando? «Exploit público desde el 14». Esto cambia la urgencia radicalmente: no es lo mismo un 9.8 teórico que un 9.8 con herramienta automatizada circulando.
5. ¿Qué hago mientras actualizo? La mitigación temporal permite ganar horas si el despliegue no puede ser inmediato.

El vector es la parte que casi nadie mira y la que más información aporta. Tomemos el del ejemplo:

Se lee de izquierda a derecha; cada par es Métrica:Valor.

Las cuatro primeras métricas describen lo fácil que es explotarlo; las tres últimas, lo que consigue el atacante. Nuestro vector dice, en lenguaje llano: cualquiera desde Internet, sin cuenta, sin engañar a nadie y sin condiciones especiales, obtiene acceso total de lectura, escritura y capacidad de tumbar el servicio. De ahí el 9.8.

Compáralo con otro vector muy distinto que también podría aparecer en un boletín:

Traducción: hace falta estar en la máquina físicamente o con sesión local, ser administrador, que además otro usuario haga algo concreto, y aun así solo se obtiene una filtración parcial de información. Mismo tipo de documento, urgencia radicalmente distinta.

Rangos de puntuación (CVSS v3.x):

La puntuación base de CVSS no es tu riesgo. Es una medida de severidad técnica en abstracto, sin conocer tu entorno. Dos matices que cambian todo:

• Una vulnerabilidad crítica (9.8) en un componente que Nimbus tiene apagado o inaccesible desde fuera puede ser un riesgo bajo para Nimbus.
• Una vulnerabilidad media (6.5) en el componente que autentica a todos los usuarios, con exploit público y expuesta a Internet, puede ser el riesgo más urgente de la semana.

Por eso las organizaciones maduras priorizan combinando CVSS + explotación activa conocida + exposición real del activo + criticidad del activo. Existen métricas complementarias para esto (temporales, ambientales, y sistemas como EPSS que estiman probabilidad de explotación); el cálculo formal del riesgo se aborda en 04-01.

La ventana de exposición es el tiempo durante el cual una vulnerabilidad existe en tus sistemas y puede ser aprovechada. Es la métrica que de verdad importa, porque es la que puedes reducir.

Sobre esa línea temporal se definen dos conceptos:

• Vulnerabilidad de día cero (0-day): aquella que es conocida y aprovechada por atacantes antes de que exista parche (a menudo antes de que el fabricante siquiera lo sepa). Se llama «día cero» porque el defensor tiene cero días para prepararse. Contra un 0-day no sirve parchear —no hay parche—; sirven la defensa en profundidad, la segmentación y la detección de comportamiento anómalo.
• Vulnerabilidad de n-day: la que ya tiene parche publicado pero sigue sin aplicarse. Es, con diferencia, la más explotada en la práctica: los atacantes automatizan la búsqueda de sistemas sin parchear porque saben exactamente qué buscar y cómo.

El dato que cambia prioridades: un 0-day es caro, escaso y se reserva para objetivos valiosos. Una PYME como Nimbus casi nunca es víctima de un 0-day; es víctima de un n-day de hace ocho meses en un servicio expuesto. Por eso el control con mejor relación coste-beneficio en Nimbus no es una herramienta sofisticada de detección: es un proceso disciplinado de actualización.

Cómo se reduce la ventana en Nimbus:

Todo lo anterior se une en una sola cadena causal. Este diagrama es el resumen de la lección:

Tres lecturas que deberías extraer de este diagrama:

1. La amenaza no se elimina; la vulnerabilidad sí. No hay ningún control que hagas en Nimbus que haga desaparecer a los grupos de ransomware. Todos tus controles actúan sobre la caja de la izquierda-abajo (vulnerabilidad) o sobre la de la derecha (impacto).
2. Sin vulnerabilidad no hay riesgo, por mucha amenaza que haya. Y sin amenaza tampoco: una vulnerabilidad en un sistema completamente aislado y sin valor tiene riesgo cercano a cero. Ambas casillas deben estar llenas.
3. Hay dos formas de reducir el riesgo. Reducir la probabilidad (cerrar la vulnerabilidad) o reducir el impacto (copias de seguridad, segmentación, seguro, plan de respuesta). Cuando no puedes hacer lo primero —caso del 0-day—, todavía te queda lo segundo. De hecho, las organizaciones que sobreviven a incidentes graves suelen haber invertido en la segunda columna.

Nada de esto se convierte todavía en un número. Cuantificar probabilidad e impacto en una matriz, decidir qué se acepta y qué se mitiga y con qué presupuesto, es el trabajo de la lección 04-01.

Errores comunes:

• Tratar CVSS como si fuera riesgo. Es el error más extendido. Un 9.8 en un componente que no usas no debe desplazar a un 6.5 en tu sistema de autenticación expuesto a Internet.
• Ignorar el vector y mirar solo el número. El vector te dice si necesitas privilegios, interacción de usuario o acceso local — información que a menudo descarta la vulnerabilidad para tu caso.
• Obsesionarse con los 0-day. Consumen atención desproporcionada. La inmensa mayoría de compromisos reales en PYMES usan vulnerabilidades con parche disponible desde hace meses.
• Pensar que el malware entra «por virus del correo». Hoy entra mayoritariamente por credenciales válidas robadas y por accesos de terceros. Es una diferencia que cambia dónde inviertes.
• Confundir CVE con CWE. Si en un informe escribes «tenemos la CWE-2026-01234», estás mezclando: las CWE no llevan año.
• Olvidar las vulnerabilidades humanas y de proceso. No aparecen en ningún escáner y son las que permiten los incidentes más caros: no revocar accesos en una baja, no tener procedimiento de aprobación de pagos.
• Suponer que «la nube lo parchea todo». El proveedor parchea su infraestructura; las imágenes de contenedor, las dependencias de Iván y la configuración de Lucía son de Nimbus.

Consejos:

• Al leer un aviso, hazte siempre las cinco preguntas del apartado 6.1 y en ese orden. La primera («¿me afecta?») descarta la mayoría.
• Escribe tus hallazgos con la cadena del apartado 8: actor → amenaza → vulnerabilidad → activo → impacto → control. Un hallazgo al que le falta una casilla suele estar mal planteado.
• Prioriza por exposición antes que por severidad: lo que da a Internet, primero.
• Automatiza el inventario de dependencias antes que el escaneo: no se puede priorizar lo que no sabes que tienes.

Para cada situación de Nimbus, indica (a) el origen de la amenaza (humana deliberada, humana accidental, fallo técnico, natural/entorno) y (b) el objetivo en términos de la tríada CIA:

1. Iván sube al repositorio público de GitHub, por error, un fichero con la clave de acceso al proveedor cloud; 11 minutos después hay 30 máquinas de cómputo arrancadas minando criptomonedas.
2. Una obra en la calle de la oficina de Valencia corta la fibra durante 8 horas.
3. Un antiguo desarrollador, cuya cuenta nunca se desactivó, accede al repositorio y modifica un script de facturación para que redondee los importes a su favor.
4. Un disco del servidor de base de datos empieza a devolver errores de lectura y algunas filas de la tabla reservas quedan ilegibles.

Llegan a Lucía tres avisos el mismo lunes. Ordénalos por urgencia real para Nimbus y justifica tu orden, indicando qué significa cada vector.

Para cada hallazgo de una revisión interna de Nimbus, indica el tipo de vulnerabilidad (software / configuración / criptográfica / diseño / humana / física) y propón un control que la reduzca. Después, redacta el hallazgo 4 con la cadena completa del apartado 8.

1. La tabla usuarios_legacy guarda contraseñas con MD5 sin sal.
2. El grupo de seguridad de la base de datos permite entrada en el puerto 5432 desde 0.0.0.0/0.
3. Cuando alguien deja Nimbus, Sara avisa por chat «cuando puedas, quítale los accesos» y no hay lista de sistemas a revisar.
4. Los portátiles de los 19 empleados en remoto no tienen cifrado de disco activado.

Solución 1

1. Origen: humana accidental (el error de Iván) — aunque la explotación posterior sea humana deliberada. Es importante ver la cadena: una amenaza deliberada aprovecha una vulnerabilidad creada accidentalmente. Objetivo: principalmente disponibilidad (recursos consumidos, degradación del servicio y coste), pero debe asumirse también compromiso de confidencialidad: esa clave pudo hacer mucho más que minar, y hasta revisar el registro de actividad del proveedor no se sabe.
2. Origen: natural/entorno. Objetivo: disponibilidad — de la oficina. Como la mitad de la plantilla ya trabaja en remoto y los sistemas están en la nube, el impacto sobre el servicio a clientes es bajo: un buen ejemplo de que la arquitectura ya actúa como control.
3. Origen: humana deliberada, insider (concretamente ex empleado con acceso no revocado; la vulnerabilidad de fondo es humana/de proceso). Objetivo: integridad en primer lugar (alteración de la lógica de facturación) y, de forma derivada, fraude económico. Si además leyó datos, hay confidencialidad.
4. Origen: fallo técnico. Objetivo: integridad (datos corruptos) y, si el servidor deja de responder, disponibilidad. Nadie ataca a nadie y el daño es real: recuerda que el impacto no depende del origen.

Solución 2

Orden de urgencia: B → C → A.

• B, primero. Vector: AV:N (desde Internet), AC:L (sin condiciones especiales), PR:N (sin cuenta previa), UI:N (sin engañar a nadie), C:H (fuga alta), I:L, A:N. Aunque su puntuación (8.2) es menor que la de A, es la única que combina exposición real + componente crítico + exploit público. Es la librería que valida las sesiones de la API pública de Nimbus: un fallo aquí es un fallo de autenticación de todo el producto. Se corrige hoy, con mitigación temporal si el despliegue tarda.
• C, segundo. Vector: AV:L (hace falta acceso local), AC:H (condiciones difíciles), PR:H (ser administrador), UI:R (necesita que alguien colabore), C:L (fuga menor). Un atacante que ya sea administrador del portátil de Lucía tiene problemas mucho mayores que este. Entra en el ciclo normal de actualización. Va antes que A solo porque el componente sí está en uso.
• A, último, pese al 9.8. El componente está desmantelado: el servicio no corre y el puerto está cerrado. Sin exposición no hay explotación posible. Ahora bien, no es «no hacer nada»: la acción correcta es desinstalar el paquete, porque un servicio olvidado que alguien reactive por descuido convierte un riesgo nulo en un riesgo crítico. Este ejercicio es exactamente el caso que ilustra por qué CVSS no es riesgo.

Solución 3

1. Criptográfica. MD5 es una función rota para este uso y, sin sal, permite el uso de tablas precalculadas. Control: migrar a un algoritmo de derivación de contraseñas con factor de coste (bcrypt, scrypt o Argon2) rehaciendo el hash en el siguiente inicio de sesión de cada usuario, y eliminar la tabla legacy cuando esté vacía. El detalle técnico se ve en 03-04.
2. De configuración (con un componente de diseño: no debería existir la posibilidad de abrirlo a Internet). Control: restringir el origen al rango privado de la VPC o al grupo de seguridad de la API; acceso administrativo solo por VPN o bastión; alerta automática si la regla vuelve a abrirse.
3. Humana / de proceso. Control: procedimiento formal de baja (offboarding) con lista cerrada de sistemas —proveedor cloud, GitHub, correo, VPN, gestor de contraseñas, herramienta de soporte—, plazo máximo de revocación (mismo día), responsable asignado y registro de la ejecución. Idealmente, cuentas centralizadas para que una única desactivación corte todos los accesos.
4. Física (con componente de configuración). Control: cifrado de disco completo obligatorio y verificado de forma centralizada, con custodia de las claves de recuperación.

Hallazgo 4 redactado con la cadena completa:

Actor de amenaza: delincuencia común oportunista (robo o pérdida de equipos). Amenaza: acceso al contenido del disco de un portátil sustraído. Vulnerabilidad: ausencia de cifrado de disco completo en los 19 portátiles del personal en remoto. Activo: información local de esos equipos — exportaciones de clientes finales, credenciales guardadas en el navegador, claves SSH de acceso a la infraestructura. Exploit: no requiere ninguno sofisticado: basta con arrancar desde un medio externo o extraer el disco. Impacto: fuga de datos personales (posiblemente de salud, en el caso de exportaciones de clínicas), acceso potencial a la infraestructura mediante las claves almacenadas, y probable obligación de notificación a la autoridad de control. Riesgo: alto, por la elevada probabilidad de pérdida o robo en movilidad y el impacto severo. Controles: cifrado de disco completo obligatorio, borrado remoto, expiración de sesiones, prohibición de almacenar exportaciones locales y uso de claves de infraestructura con frase de paso y vigencia corta.

Nota sobre implicaciones legales: la obligación de notificar una brecha de datos personales, sus plazos y sus destinatarios dependen de la naturaleza de los datos y del caso concreto. Las referencias de este curso son orientativas y con fines formativos: valida siempre estas decisiones con el responsable de cumplimiento o con un profesional del ámbito jurídico.

Ahora tienes el mapa. Sabes clasificar amenazas por origen —humanas deliberadas, humanas accidentales, fallos técnicos y del entorno— y por objetivo según qué propiedad de la tríada CIA atacan, y has comprobado que el impacto no depende del origen: un DROP TABLE accidental y un ransomware dejan a los clientes de Nimbus igual de parados. Has recorrido las familias de malware distinguiéndolas por su mecanismo de propagación, y has identificado las dos que más deberían preocupar a una PYME como Nimbus: el ransomware que entra por credenciales válidas y el cryptominer que llega por una clave cloud filtrada. Has visto que las amenazas internas se dividen en maliciosas, negligentes y comprometidas, y que la consultora externa con acceso remoto es, en la práctica, un insider fuera del alcance de RRHH.

En el lado de las debilidades has repasado los seis tipos de vulnerabilidad con casos concretos de Nimbus —el bucket sin bloqueo de acceso público, la librería de tokens sin actualizar, PostgreSQL escuchando en 0.0.0.0— y has extraído la lección que más rentabilidad da: la mayoría de las brechas reales nacen de configuración, no de código exótico. Y has aprendido a leer el lenguaje común de la industria: CWE para la clase, CVE para la instancia, CVSS para la severidad, descomponiendo el vector métrica a métrica y entendiendo por qué una puntuación de 9.8 no siempre gana a una de 8.2. Cierras con la distinción entre 0-day y n-day, y con la idea de que la ventana de exposición es la variable sobre la que de verdad puedes actuar.

Sabes qué te puede pasar y por dónde. Falta saber cómo se construye un sistema para que eso no pase. En la siguiente lección, Principios de la Seguridad Informática (01-03), veremos las reglas de diseño que guiarán todas las decisiones del resto del curso: mínimo privilegio, defensa en profundidad, fallo seguro, separación de funciones, confianza cero y la mentalidad de «asume la brecha» — cada una aplicada a una decisión real de la arquitectura de Nimbus.