Los tres apartados anteriores te han dado el vocabulario, el catálogo de amenazas y los principios de diseño. Todo eso es inaplicable mientras no respondas a una pregunta prosaica: ¿qué tiene exactamente Nimbus Reservas? No puedes proteger lo que no sabes que existe, no puedes reducir una superficie que no has medido y no puedes priorizar sin saber quién podría atacarte y con qué medios. Esta lección cierra el módulo construyendo esas tres piezas —inventario de activos, superficie de ataque y actores de amenaza— y las une con una primera herramienta de análisis: STRIDE aplicado a un diagrama de flujo de datos de la propia arquitectura de Nimbus. Al terminar tendrás la foto completa del terreno sobre el que trabajaremos durante los seis módulos restantes.

1. Qué es un activo y por qué el inventario es el control número uno
2. Tipos de activos y el inventario de Nimbus Reservas
3. Clasificación de la información: público, interno, confidencial, restringido
4. Descubrir lo que ya tienes: inventario técnico con herramientas del sistema
5. La superficie de ataque y sus cinco dimensiones
6. Técnicas de reducción de superficie
7. Actores de amenaza: quién, por qué y con qué capacidad
8. Introducción práctica al modelado de amenazas con STRIDE
9. Cierre del módulo

Un activo es cualquier elemento que tiene valor para la organización y que, por tanto, merece protección.

La palabra clave es valor, y el valor no es solo económico. Un fichero de logs no vale dinero, pero sin él Nimbus no puede investigar un incidente ni demostrar qué ocurrió: su valor es probatorio. La reputación no aparece en ningún balance, pero es lo que hace que una clínica renueve el contrato.

Por qué el inventario aparece el primero en todas las listas de controles serias:

• No puedes proteger lo que no sabes que existe. El servidor de pruebas que Iván levantó hace ocho meses «para una demo», con una copia de datos reales y sin parchear desde entonces, no está en ninguna lista. Es exactamente lo que un escaneo automatizado encuentra.
• No puedes priorizar sin criticidad. Si todos los sistemas parecen igual de importantes, se protegen todos igual de mal.
• No puedes responder a un incidente sin saber qué hay. La primera pregunta en una brecha es «¿a qué datos ha podido acceder?». Sin inventario, la respuesta honesta es «no lo sabemos», que ante un cliente o un regulador es la peor de las respuestas.
• No puedes aplicar ningún parche con seguridad. Cuando salga la CVE de la lección 01-02, la pregunta «¿nos afecta?» solo se responde rápido con inventario.

Un dato incómodo del sector: en la mayoría de brechas relevantes en PYMES, el punto de entrada fue un activo que la organización había olvidado que tenía. Un subdominio antiguo, un entorno de pruebas, una cuenta de un ex empleado, una integración desconectada pero con credencial viva.

Los cuatro campos que convierten una lista en un inventario útil:

Los activos no son solo servidores. Una clasificación práctica distingue seis tipos:

Los dos últimos se olvidan sistemáticamente y son decisivos. Lucía es un activo: es la única persona que sabe restaurar la infraestructura completa. Si Lucía se va o está ilocalizable durante un incidente, Nimbus tiene un problema de disponibilidad tan real como si se cayera un servidor. Y la reputación es un activo: la mayor parte del daño económico de una brecha en un SaaS no viene de la multa, viene de los clientes que no renuevan.

Tres observaciones sobre esta tabla que valen más que la tabla misma:

1. A-05 (la cuenta del proveedor cloud) es el activo del que dependen casi todos los demás. Comprometer esa cuenta anula la mayoría de los controles simultáneamente. En el lenguaje de la lección 01-03: es el punto que derriba varias capas de defensa a la vez, y por eso merece protección desproporcionada.
2. A-19 (el acceso de la consultora) tiene criticidad crítica y propietario Marta, no Lucía. Es deliberado: el riesgo de ese activo es contractual y de gobierno, no técnico. Se desarrolla en 04-04.
3. A-22 aparece con clasificación «a revisar». Es honesto y es lo que suele pasar: nadie está seguro de si preproducción tiene datos reales. Un inventario que refleja las dudas es más útil que uno que las esconde; esa celda es, de hecho, la primera tarea de seguridad de la semana.

Cómo se mantiene vivo un inventario. El inventario no es un documento, es un proceso. Tres reglas prácticas: (a) que la infraestructura se defina como código, de modo que el repositorio sea el inventario; (b) que el alta de cualquier activo nuevo requiera propietario y clasificación desde el primer día; (c) una revisión trimestral corta buscando específicamente lo que sobra —cuentas, entornos, integraciones y subdominios que ya no se usan.

Clasificar significa decidir cuánta protección merece cada dato. Sin clasificación, o se protege todo al máximo (caro, insostenible y contraproducente) o nada de forma consistente.

Cuatro niveles bastan para una empresa como Nimbus. Más niveles no aportan precisión: aportan confusión.

Regla 1: la clasificación se hereda hacia arriba. Un fichero que contiene un solo dato restringido es restringido. Un informe agregado que mezcla datos internos y confidenciales es confidencial. Los conjuntos toman la clasificación de su elemento más sensible.

Regla 2: la agregación puede subir el nivel. El historial de una cita aislada es un dato restringido. La tabla completa de 400.000 citas de clínicas de fisioterapia es cualitativamente peor: no solo suma, se convierte en un mapa de personas con dolencias. Ese cambio de naturaleza es el que hace que las exportaciones masivas merezcan controles propios (lo diseñaste en el ejercicio 3 de la lección anterior).

Regla 3: el contexto define la sensibilidad. «Ana Ruiz, 15/03, 17:00» parece inocuo. En la agenda de una clínica de rehabilitación revela indirectamente información de salud. Nimbus no puede decir «yo solo gestiono agendas»: gestiona agendas cuyo contenido, por contexto, es sensible.

Nota sobre implicaciones legales: la categoría de «datos que revelan información de salud» y las obligaciones asociadas (bases de legitimación, medidas reforzadas, evaluaciones de impacto) tienen un tratamiento normativo específico que se aborda en la lección 06-03. La calificación concreta de los datos de tu organización debe validarse con el responsable de cumplimiento o con un profesional del ámbito jurídico.

Un activo de información que ya no se necesita deja de ser un activo y pasa a ser solo pasivo de riesgo. Los CSV que Rubén generó hace un año, los volcados de base de datos en el portátil de Iván, las copias de hace cinco años: aportan cero valor y todo el riesgo. La política de retención —cuánto se guarda cada cosa y cuándo se destruye— es parte de la clasificación, no un apéndice.

El inventario documental se contrasta siempre con la realidad, porque la realidad siempre tiene sorpresas. Empecemos por el activo A-01: el servidor de base de datos.

Importante: todos los comandos de esta lección se ejecutan sobre sistemas propios de Nimbus, con autorización. Escanear sistemas ajenos sin permiso expreso es ilegal; la ética y el marco legal de estas actividades se tratan en 06-06.

Anatomía del comando, opción a opción:

Salida en el servidor de base de datos de Nimbus:

Cómo se lee esto, línea a línea:

• Líneas 1 y 2 (postgres, puerto 5432): escucha en 127.0.0.1 (solo el propio equipo) y en 10.0.2.15 (la IP privada de la VPC). Esto es correcto: no aparece 0.0.0.0, luego no escucha en interfaces públicas. Compáralo con el hallazgo de la lección 01-02, donde sí lo hacía.
• Línea 3 (sshd, puerto 22): escucha en 0.0.0.0, es decir, en todas las interfaces. Aquí hay que mirar la segunda capa: aunque el sistema escuche en todas, el grupo de seguridad del proveedor puede restringir el origen. Si no lo hace, es un hallazgo: el acceso administrativo debería llegar solo por bastión o VPN.
• Línea 4 (node_exporter, puerto 9100): métricas de monitorización, escuchando en todas las interfaces. Expone información detallada del sistema sin autenticación. Hallazgo típico y muy frecuente: se instala para monitorizar y nadie lo restringe.
• Línea 5 (python, puerto 8000): ¿qué hace un proceso Python escuchando en el servidor de base de datos? Este es exactamente el tipo de sorpresa que justifica el ejercicio. Podría ser el script de una demo antigua, un servidor de desarrollo olvidado o algo peor. Requiere investigación inmediata.
• Línea 6 (systemd-resolve, puerto 53 en 127.0.0.53): el resolvedor de DNS local. Solo local: correcto.

La regla de oro para leer esta salida: fíjate primero en la dirección local, no en el puerto. 127.0.0.1 es solo local (sin exposición). Una IP privada (10.x, 192.168.x, 172.16-31.x) es exposición interna. 0.0.0.0 o :: significa todas las interfaces, y ahí es donde empieza el trabajo.

Traducción: Iván levantó un servidor HTTP estático el día de una demo y lleva 94 días corriendo, sirviendo el contenido de /var/tmp/demo a cualquiera que llegue al puerto 8000. Es un activo no inventariado, sin propietario declarado, sin parchear y con contenido desconocido. En la lección 01-02 lo llamaríamos vulnerabilidad de configuración; aquí es lo que ilustra por qué el inventario es el control número uno.

El sistema es solo la mitad de la historia. La otra mitad es el cortafuegos del proveedor:

El diagnóstico completo solo aparece cruzando las dos capas. El puerto 5432 escuchaba en la IP privada y además está restringido a la VPC: doble capa correcta. El puerto 22, en cambio, escucha en todas las interfaces y está abierto a 0.0.0.0/0: cualquier bot de Internet puede intentar autenticarse contra el SSH de la base de datos de Nimbus. Eso es un hallazgo de prioridad alta.

Las herramientas especializadas de descubrimiento y escaneo se ven en 05-01 y 05-03; aquí lo importante es el método: primero mira lo tuyo, con lo que ya tienes instalado.

La superficie de ataque es el conjunto de todos los puntos por los que un atacante podría intentar entrar, extraer datos o afectar al sistema.

Es una propiedad medible y reducible, y esa es la buena noticia: a diferencia de las amenazas, la superficie sí está bajo tu control. Cada punto que eliminas es un punto que no hay que defender, vigilar ni parchear nunca más.

La superficie no es estática: respira. Cada despliegue de Iván puede añadir endpoints. Cada contratación añade una persona. Cada integración nueva añade un tercero. Por eso se mide de forma continua y no una vez al año.

Superficie expuesta ≠ superficie total. Hay que distinguir:

• Superficie externa: lo alcanzable desde Internet sin credenciales. Es la más urgente, porque cualquiera del mundo puede tocarla.
• Superficie autenticada: lo alcanzable con una cuenta válida (incluida una cuenta de prueba gratuita, si la hay).
• Superficie interna: lo alcanzable tras el primer compromiso. Es la que determina cuánto se propaga un incidente.

Nimbus tiende a mirar solo la primera. Pero recuerda el principio «asume la brecha» de la lección anterior: la superficie interna es la que decide si un portátil comprometido acaba en una anécdota o en un ransomware de toda la infraestructura.

Reducir superficie es, con diferencia, la forma más barata de mejorar la seguridad: lo que no existe no se puede atacar, no hay que parchearlo, no hay que monitorizarlo y no aparece en la próxima auditoría.

Qué se ha reducido y por qué importa:

• Construcción en dos etapas: los compiladores y las herramientas de instalación se quedan en la primera etapa y no llegan a producción. Un atacante no puede compilar nada.
• Imagen distroless: no hay sh, ni bash, ni curl, ni apt. Muchas técnicas de post-explotación asumen que hay una shell disponible; aquí, sencillamente, no la hay.
• USER 10001: el proceso no corre como root. Una ejecución de código arbitrario no da control del contenedor.
• Efecto colateral valioso: menos paquetes significa menos CVEs que revisar cada semana. La reducción de superficie también reduce el trabajo de mantenimiento.

Los detalles de seguridad en contenedores se desarrollan en 05-07; aquí basta con ver el principio en acción.

Un actor de amenaza es quien materializa una amenaza. Conocerlos importa porque la motivación determina el objetivo y la capacidad determina hasta dónde puede llegar — y ambos deciden dónde inviertes.

Es el punto más importante de este apartado, porque corrige el error mental más caro en una PYME: «a nosotros no nos va a atacar nadie, no somos interesantes».

La premisa es falsa porque el atacante oportunista no elige víctimas: encuentra sistemas. El proceso es completamente automatizado:

Nada en esta cadena requiere que alguien haya oído hablar de Nimbus. Tres consecuencias prácticas:

1. La exposición pesa más que el atractivo. Lo que decide si te comprometen no es lo interesante que seas, sino si tienes algo abierto y sin parchear. Ese SSH en 0.0.0.0/0 del apartado 4.3 recibe intentos de autenticación cada pocos minutos, todos los días, sin que nadie sepa qué es Nimbus.
2. Los controles básicos rinden desproporcionadamente. Parchear, cerrar lo que no se usa, MFA en todas las cuentas administrativas y copias fuera de alcance neutralizan a la inmensa mayoría de estos actores. No hace falta un centro de operaciones de seguridad para defenderse de un bot.
3. El acceso inicial se revende. Existen intermediarios que comprometen sistemas y venden el acceso a grupos de ransomware. Por eso «solo me han minado criptomonedas, no es grave» es una conclusión peligrosa: quien entró pudo dejar la puerta abierta, y quien la use después puede tener otros planes.

Frente al APT, la conclusión honesta es distinta: si un grupo con recursos estatales decidiera atacar específicamente a Nimbus, Nimbus no puede detenerlo. Lo que sí puede es detectar y limitar el alcance, que es exactamente el enfoque «asume la brecha» de la lección 01-03. Y hay un matiz relevante: Nimbus podría ser un objetivo intermedio — no por sus datos, sino por ser proveedor de otros. Los ataques a la cadena de suministro convierten a empresas pequeñas en puentes hacia empresas grandes.

El modelado de amenazas es un ejercicio estructurado para responder, sobre un diseño concreto: ¿qué puede salir mal aquí? Se hace antes de construir (seguridad desde el diseño) o al revisar lo existente, y no requiere herramientas: bastan un diagrama y un método.

STRIDE es el método más usado para empezar. Es una lista de seis categorías de amenaza, cada una asociada a la propiedad de seguridad que viola:

Reconocerás las seis: son las propiedades de la lección 01-01 vistas desde el lado del atacante. Esa es toda la gracia de STRIDE — convierte una lista de propiedades en una lista de preguntas.

El modelado se hace sobre un diagrama, no sobre la aplicación entera. Un DFD tiene cuatro elementos: entidades externas (actores fuera de tu control), procesos (tu código), almacenes de datos y flujos. Y un quinto elemento que es donde vive casi todo el valor del ejercicio: las fronteras de confianza, líneas que separan zonas con distinto nivel de confianza.

Cómo se dibuja un DFD útil (te servirá para el ejercicio):

1. Empieza por las entidades externas: todo lo que no controlas. Ahí es donde entra lo inesperado.
2. Añade tus procesos y almacenes.
3. Dibuja los flujos y numéralos: los números te permiten enumerar amenazas de forma ordenada y no olvidarte de ninguno.
4. Traza las fronteras de confianza. Regla práctica: cada vez que un dato cruza una frontera, hay que analizarlo. Ahí es donde se concentran las amenazas.
5. No dibujes toda la empresa. Un DFD de un flujo concreto, bien hecho, vale más que un diagrama gigante que nadie mira.

Se recorre el diagrama elemento por elemento preguntando las seis preguntas. Extracto del análisis de Nimbus:

Tres reglas para que el ejercicio sea productivo:

• No busques las seis letras en todos los elementos. Algunas no aplican. Es normal y no es un fallo del método.
• Prioriza las fronteras. Los flujos que cruzan una línea de confianza (F1, F2, F8, F11) concentran las amenazas más relevantes.
• Cada amenaza debe terminar en una decisión: mitigar, aceptar, transferir o eliminar. Un modelado que produce una lista bonita y ninguna decisión no ha servido de nada. La formalización de esas decisiones —con probabilidad, impacto y matriz— se hace en 04-01.

Este es el punto en el que las cuatro lecciones se unen:

Tienes el mapa del terreno. A partir de aquí, cada módulo profundiza en una parte: cómo se ataca y se defiende (2), cómo se protege la información con matemáticas (3), cómo se gestiona el riesgo y se responde (4), qué herramientas se usan (5), qué exige la normativa (6) y cómo aplicarlo todo a un caso completo (7).

Errores comunes:

• Confundir inventario con lista de servidores. El inventario incluye datos, servicios SaaS, dominios, personas y terceros. Los activos que no son servidores son los que más se olvidan y los que más incidentes causan.
• Hacer el inventario una vez. Un inventario de hace un año describe una empresa que ya no existe.
• Inventariar sin propietario. Un activo sin responsable no se parchea, no se clasifica y no se retira. Si tuvieras que elegir un solo campo, elige propietario.
• Clasificar todo como confidencial. Si todo es confidencial, nada lo es: el equipo deja de distinguir y trata todo con el mismo (bajo) cuidado.
• Olvidar la superficie interna. Muchos se miden solo desde fuera. La superficie interna es la que determina el alcance de un compromiso.
• Creer que «no somos objetivo». Los ataques oportunistas no eligen; encuentran. Es el error de razonamiento más caro en una PYME.
• Modelar amenazas sin fronteras de confianza. Un DFD sin fronteras convierte el ejercicio en un dibujo bonito. Las fronteras son donde están las amenazas.
• Terminar el modelado sin decisiones. Una lista de amenazas sin mitigación asignada y sin responsable no cambia nada.

Consejos:

• Empieza el inventario por lo que da a Internet y por lo que contiene datos restringidos. Eso ya cubre el grueso del riesgo.
• Dedica una hora al trimestre exclusivamente a buscar lo que sobra: subdominios, entornos, cuentas, integraciones y credenciales sin uso. Es la hora de seguridad más rentable del trimestre.
• Cuando revises un servidor, cruza siempre dos capas: lo que escucha el sistema (ss) y lo que permite el cortafuegos del proveedor. Una sola capa da un diagnóstico falso.
• Haz tu primer modelado STRIDE sobre un solo flujo —el de reserva, por ejemplo— y termínalo. Un modelado pequeño y acabado enseña más que uno ambicioso y abandonado.
• Guarda el DFD junto al código, en el repositorio. Así se actualiza cuando cambia la arquitectura y no se convierte en un documento muerto.

Durante una revisión aparecen cinco activos de Nimbus que no estaban en la tabla del apartado 2.1. Para cada uno indica: tipo, propietario razonable, criticidad, clasificación y una acción inmediata.

1. El servidor demo.nimbusreservas.example, levantado hace 94 días por Iván, sirviendo ficheros estáticos en el puerto 8000 desde el servidor de base de datos.
2. Una hoja de cálculo compartida por Sara con nombres, DNI, salarios y cuentas bancarias de los 38 empleados, en una carpeta de la nube con enlace «cualquiera con el enlace puede ver».
3. Una cuenta de servicio en GitHub llamada nimbus-deploy-bot con un token personal sin caducidad y permisos de escritura en todos los repositorios.
4. Un NAS en la oficina de Valencia donde se copiaban las bases de datos hasta hace dos años; sigue encendido y nadie recuerda la contraseña de administración.
5. El grupo de WhatsApp «Nimbus Soporte Urgente», donde Rubén comparte capturas de pantalla de incidencias de clientes.

Este es el resultado de sudo ss -tulpn en el servidor de aplicaciones de Nimbus. Para cada línea indica si es aceptable o no, qué riesgo introduce y qué acción concreta de reducción de superficie aplicarías.

Nimbus va a lanzar una funcionalidad nueva: recordatorios por SMS. El flujo es:

1. El personal de la clínica activa los recordatorios desde el panel web.
2. Un worker consulta cada hora en PostgreSQL las citas de las próximas 24 horas.
3. Por cada cita, llama a la API de un nuevo proveedor de SMS (tercero) enviando el teléfono del paciente y un texto con la fecha, la hora y el nombre del servicio («Rehabilitación de rodilla»).
4. El proveedor devuelve un identificador de envío que se guarda en la tabla envios_sms.
5. El proveedor envía un webhook a la API de Nimbus cuando el SMS se entrega o falla.

Se pide: (a) dibuja el DFD en mermaid con sus fronteras de confianza; (b) identifica al menos una amenaza por cada letra de STRIDE, indicando el elemento o flujo afectado; (c) propón una mitigación para cada una.

Solución 1

Comentarios clave:

• El caso 2 es el más grave en términos de datos personales y probablemente el más frecuente en la vida real. Un enlace de tipo «cualquiera con el enlace» es una publicación: los enlaces se reenvían, se indexan y se filtran.
• El caso 3 ilustra la reducción de superficie en la cadena de suministro: un token sin caducidad con acceso total a todos los repositorios es una llave maestra que nunca expira.
• El caso 4 muestra por qué el inventario debe incluir la retirada: un activo olvidado sigue siendo un pasivo de riesgo mientras esté encendido.
• El caso 5 recuerda que la superficie humana y la de terceros no siempre pasan por sistemas corporativos.

Solución 2

Regla de decisión que resume el ejercicio: para cada servicio en escucha, pregúntate si alguien lo necesita; si nadie lo necesita, elimínalo; si alguien lo necesita, restringe quién puede llegar. Aplicando solo eso, esta máquina pasa de seis puertas abiertas a una, controlada.

Solución 3

(a) DFD del flujo de recordatorios por SMS:

(b) y (c) Amenazas STRIDE y mitigaciones:

Amenaza transversal que conviene añadir (buena práctica al modelar): el flujo introduce un nuevo tercero en la cadena de suministro, con acceso a teléfonos de pacientes y, si no se minimiza, a información sobre su salud. Esto requiere evaluación del proveedor, contrato de encargo de tratamiento, y decidir qué pasa con esos datos cuando se termine la relación. Es materia de 04-04 y 06-03.

Nota sobre implicaciones legales: este ejercicio toca tratamiento de datos personales y su comunicación a un tercero, con datos que pueden revelar información de salud. Las decisiones concretas —base de legitimación, información al interesado, contrato con el encargado, necesidad de evaluación de impacto— deben validarse con el responsable de cumplimiento o con un profesional del ámbito jurídico. Lo aquí expuesto tiene fines exclusivamente formativos.

Has cerrado el módulo con la pieza más práctica de las cuatro. Sabes que un activo es todo lo que tiene valor —información, software, hardware, servicios, personas e intangibles como la reputación— y has construido el inventario de Nimbus con los cuatro campos que lo hacen útil: propietario, criticidad, clasificación y dependencias. Ese inventario ha revelado dos cosas que ninguna herramienta te habría dicho: que la cuenta del proveedor cloud es el activo del que dependen casi todos los demás, y que hay celdas con dudas —como la clasificación de preproducción— que son, precisamente, el primer trabajo pendiente. Has aprendido a clasificar la información en cuatro niveles y las tres reglas que evitan los errores habituales: la clasificación se hereda hacia arriba, la agregación puede subir el nivel y el contexto define la sensibilidad — por eso una agenda de fisioterapia no es «solo una agenda».

Has contrastado el papel con la realidad usando ss -tulpn y descubierto un servidor olvidado corriendo desde hace 94 días, y has aprendido la regla que hace útil esa salida: mira la dirección local antes que el puerto, y cruza siempre la capa del sistema con la del cortafuegos del proveedor. Sobre esa foto has medido la superficie de ataque en sus cinco dimensiones —red, software y APIs, humana, física y cadena de suministro— y has visto que reducirla es la inversión más rentable que existe: lo que no está, no se ataca, no se parchea y no se vigila. Has conocido a los actores de amenaza y has corregido el error de razonamiento más caro de cualquier PYME: el atacante oportunista no elige víctimas, encuentra sistemas, y por eso la exposición pesa más que el atractivo. Y has dado tus primeros pasos con STRIDE sobre un diagrama de flujo de datos de Nimbus, aprendiendo que el valor del ejercicio está en las fronteras de confianza y en terminar cada amenaza con una decisión.

Con esto se cierra el módulo 1. Tienes el vocabulario, el catálogo de amenazas, los principios de diseño y el mapa exacto de lo que hay que proteger en Nimbus. A partir de ahora dejamos de describir el terreno y entramos en el conflicto. En el Módulo 2: Ciberseguridad delimitaremos el alcance de la disciplina y sus marcos de referencia, recorreremos los tipos de ataque que se ejecutan contra sistemas como el de Nimbus, estudiaremos a fondo la ingeniería social y el phishing —la vía por la que entran la mayoría de los incidentes reales—, veremos las medidas de protección que los contrarrestan, profundizaremos en identidad, autenticación y control de acceso, y analizaremos casos de estudio de incidentes reales para extraer las lecciones que se repiten una y otra vez. Empezamos por Definición y Alcance de la Ciberseguridad (02-01).