Cerramos el módulo anterior con el mapa del terreno de Nimbus Reservas: su inventario de 22 activos, su superficie de ataque medida en cinco dimensiones, los actores que podrían atacarla y un primer modelado STRIDE sobre su arquitectura. Ahora entramos en el conflicto. Pero antes de recorrer ataques y defensas conviene delimitar el campo: qué es exactamente la ciberseguridad, qué abarca, cómo se organiza la disciplina y quién hace qué. Sin ese mapa, la seguridad se convierte en una colección desordenada de medidas —un antivirus por aquí, un cortafuegos por allá— sin manera de saber qué falta. Esta lección te da la estructura: los dominios en los que se divide el trabajo, los marcos de referencia que lo organizan (con el NIST Cybersecurity Framework como columna vertebral), los roles y equipos de la industria y su traducción a una empresa de 38 personas, y el ciclo de vida de un ataque, que será el esqueleto sobre el que se construyen las cinco lecciones siguientes.

1. Qué es la ciberseguridad y en qué se diferencia de la seguridad de la información
2. Los dominios de la ciberseguridad y quién los lleva en una PYME
3. Marcos de referencia: el NIST Cybersecurity Framework
4. Otros marcos del mapa: ISO/IEC 27001, CIS Controls y MITRE ATT&CK
5. Roles y equipos: Blue Team, Red Team, Purple Team, SOC y CSIRT
6. El ciclo de vida de un ataque: Cyber Kill Chain y ATT&CK
7. Qué NO es ciberseguridad: tres mitos caros
8. El mapa del módulo 2

En la lección 01-01 establecimos la distinción entre los tres términos y quedó fijada; aquí solo la retomamos para colocar el foco de este módulo.

La palabra que define la ciberseguridad es adversario. La seguridad de la información se ocupa también de accidentes, errores y desastres naturales. La ciberseguridad se ocupa específicamente de alguien —persona o programa automatizado— que quiere que algo salga mal y que se adapta cuando le pones una barrera.

Esa diferencia tiene una consecuencia práctica enorme:

• Un fallo de disco no cambia de estrategia cuando pones un RAID. Un atacante sí cambia de vector cuando cierras un puerto.
• Por eso la ciberseguridad es antagónica y evolutiva: no es un estado que se alcanza, es una competición continua contra un oponente inteligente que también aprende. Esta es la idea del «ciclo continuo» de 01-01, ahora con nombre y apellidos.

En la práctica profesional los tres términos se usan como sinónimos y nadie te va a corregir. Lo importante no es el vocabulario, sino no dejar huecos: si Nimbus solo piensa en «ciberseguridad» entendida como sistemas, se olvidará de la hoja de nóminas impresa sobre la mesa y del dato que Rubén dicta por teléfono a quien dice ser el administrador de una clínica. Este módulo se centra en el adversario; el papel y el teléfono también aparecen, porque el adversario los usa.

La disciplina se divide en dominios: áreas de trabajo con técnicas, herramientas y perfiles profesionales propios. En una empresa grande cada dominio es un equipo; en Nimbus, con 38 personas, cada dominio es una responsabilidad asignada a alguien que además hace otras cosas. Esa es la traducción realista, y es la que hacemos en la última columna.

Tres lecturas de esta tabla que importan más que la tabla:

1. Todos los nombres se repiten. Lucía aparece en cinco dominios. Eso no es un defecto del ejemplo: es la realidad de una PYME y es en sí mismo un riesgo —el que ya identificaste como A-21, «conocimiento operativo de Lucía»—. La respuesta no es contratar diez especialistas, sino priorizar, automatizar y documentar para que el conocimiento no viva en una sola cabeza.
2. Ningún dominio puede estar vacío. Si nadie tiene asignado el factor humano, nadie diseña la defensa contra el vector por el que entran la mayoría de los incidentes. Un dominio sin dueño es un dominio sin defensa; es la aplicación de la regla del propietario del inventario de 01-04, ahora a las funciones y no a los activos.
3. Los dominios se solapan y ese solape es donde se pierden las cosas. ¿Quién revisa los permisos IAM del bucket de adjuntos: la persona de nube o la de identidades? En Nimbus son la misma, pero en cuanto crezca habrá que decidirlo explícitamente. Las brechas suelen ocurrir en las costuras entre dominios, no en el centro de ninguno.

Un marco de referencia es una estructura que organiza el trabajo de seguridad para que puedas responder a dos preguntas incómodas: ¿qué nos falta? y ¿por dónde empezamos? Sin marco, la seguridad avanza por impulsos: se compra lo que un comercial vendió bien o lo que asustó en una noticia.

El NIST Cybersecurity Framework (CSF), en su versión 2.0, es el más útil para empezar porque no es una lista de productos ni una certificación: es una descripción de funciones que cualquier organización debe cubrir, del tamaño que sea.

Las seis funciones, con la pregunta que responde cada una y su estado real en Nimbus:

Por qué este marco es tan valioso para una PYME: la tabla anterior, hecha en una hora en una pizarra, ya es un diagnóstico. Nimbus descubre que su debilidad no está donde creía —«nos falta un cortafuegos mejor», que sería Proteger— sino en Detectar, Responder y Gobernar. Y son precisamente las funciones que casi ningún producto te vende, porque no se compran: se organizan.

El error de reparto más común. Las organizaciones concentran el 90 % del esfuerzo en Proteger porque es lo que tiene forma de producto. Pero el principio «asume la brecha» de 01-03 dice que la protección fallará alguna vez; cuando falle, lo único que reduce el daño es lo bien que detectas, respondes y recuperas. Un equipo que detecta en 20 minutos y contiene en una hora sufre un incidente. Uno que detecta a los tres meses sufre una brecha.

Nota: la versión 2.0 del CSF añadió la función Gobernar precisamente porque la experiencia mostró que los fallos rara vez son técnicos en su raíz: son fallos de decisión, de asignación de responsabilidad o de supervisión de terceros. Los detalles normativos y de certificación se tratan en 06-02; aquí nos quedamos con el mapa.

No hay un marco único, y no compiten entre sí: responden a preguntas distintas. Conocer cuál sirve para qué evita perder meses aplicando el equivocado.

Cómo se combinan en la práctica, que es lo que casi nunca se explica:

• El CSF te dice qué funciones cubrir → es el índice.
• Los CIS Controls te dicen qué hacer primero → es la lista de tareas. Su «Grupo de Implementación 1» (IG1) está pensado exactamente para organizaciones del tamaño de Nimbus, con recursos limitados.
• ATT&CK te dice contra qué comprobarlo → es el examen. Cada técnica del catálogo es una pregunta: «si esto pasara aquí, ¿lo veríamos?».
• ISO 27001 te dice cómo demostrarlo → es el certificado que enseñas a un cliente.

Para Nimbus hoy, la respuesta razonable es: diagnóstico con CSF, ejecución con CIS IG1, verificación con ATT&CK e ISO cuando el mercado lo pida. Perseguir la certificación antes de tener los básicos es construir el tejado antes que los cimientos — y además sale caro.

El vocabulario de equipos viene del ámbito militar y aparece constantemente en la literatura y en las ofertas de empleo. Conviene entenderlo, y conviene sobre todo entender cómo se traduce cuando no tienes equipos.

Dos matices que se confunden a menudo:

• Red Team ≠ test de penetración. Un test de penetración busca encontrar tantas vulnerabilidades como sea posible en un alcance acotado y con la organización avisada. Un ejercicio de equipo rojo busca alcanzar un objetivo concreto («llegar a la base de datos de clientes») imitando a un adversario real, y evalúa tanto las defensas como la capacidad de detección. Se desarrolla en 05-03.
• SOC ≠ CSIRT. El SOC vigila y detecta; el CSIRT responde cuando ya hay incidente confirmado. En una empresa pequeña son la misma persona, pero la distinción de funciones sigue siendo útil, porque vigilar y responder requieren estados mentales opuestos: uno es rutina sostenida, el otro es crisis.

Nimbus no tiene ni tendrá un SOC. Y no lo necesita. Lo que sí necesita es que ninguna de las cinco funciones esté a cero. La traducción realista:

La regla del equipo pequeño: con recursos limitados, la prioridad no es hacer muchas cosas mal, sino elegir pocas y hacerlas de verdad. Diez alertas que nadie mira valen menos que dos que alguien atiende siempre. Cinco políticas sin aplicar valen menos que una aplicada.

Este apartado es el más importante de la lección, porque estructura todo el módulo. Un ataque real no es un evento instantáneo: es una secuencia de fases, y esa secuencia es una buena noticia para el defensor. Si el atacante debe encadenar siete pasos y tú rompes uno, el ataque no completa su objetivo.

La Cyber Kill Chain, formulada por Lockheed Martin, describe siete fases:

Qué defensa corresponde a cada fase, que es para lo que sirve el modelo:

Las tres ideas que hay que llevarse:

1. La defensa no tiene que ser perfecta en todas las fases; tiene que funcionar en una. Esto es exactamente la defensa en profundidad de 01-03, ahora vista sobre el eje del tiempo en lugar del eje de las capas.
2. Cuanto antes rompas la cadena, más barato sale. Cerrar un puerto (fase 3) cuesta cinco minutos. Responder a una exfiltración (fase 7) cuesta meses, dinero y clientes.
3. La detección importa en todas las fases, no solo en la última. Cada fase deja señales. El problema de Nimbus no es que no haya señales: es que nadie las mira.

La Kill Chain es un modelo lineal y sencillo, ideal para explicar. Tiene dos limitaciones: los ataques reales no son estrictamente lineales (se vuelve atrás, se itera) y el modelo se queda corto en todo lo que ocurre una vez dentro. Ahí entra MITRE ATT&CK, un catálogo de tácticas (el para qué) y técnicas (el cómo) observadas en incidentes reales.

Fíjate en el desequilibrio: la última fase de la Kill Chain se expande en seis tácticas de ATT&CK. Eso refleja la realidad: la mayor parte del trabajo de un atacante ocurre después de entrar —descubrir la red, robar credenciales, moverse lateralmente, recolectar datos— y suele durar días o semanas. Es precisamente la ventana en la que un defensor con buena detección todavía puede ganar.

El uso práctico de ATT&CK para Nimbus no es memorizarlo, sino usarlo como lista de comprobación de detección: coger diez técnicas relevantes para su entorno y preguntarse, una por una, «si esto ocurriera hoy, ¿lo veríamos en algún log?». Se desarrolla en 05-02.

Los mitos no son inocentes: cada uno se traduce en una decisión concreta que deja un hueco concreto.

Por qué es falso. Repasa el módulo 1: la clasificación de la información la decide quien conoce el negocio, no quien administra el servidor. La verificación de una transferencia la hace Sara. Quien detecta un correo raro es cualquiera de los 38. Quien decide si se acepta un riesgo es Marta.

Consecuencia de creerlo. Si Lucía es «la responsable de seguridad», Sara no se siente responsable de verificar una cuenta bancaria por teléfono, e Iván no se siente responsable de validar entradas. La seguridad queda a cargo de una persona que no controla la mayoría de los puntos de fallo.

Formulación correcta: IT y seguridad son facilitadores y coordinadores; la responsabilidad es distribuida y la rendición de cuentas es de la dirección. Esa es la función Gobernar del CSF.

Por qué es falso. Ambos son controles útiles, y ninguno cubre lo que más ocurre:

Consecuencia de creerlo. Se compra producto y se declara resuelto el problema. Pero las tres funciones que más le faltan a Nimbus —Gobernar, Detectar, Responder— no se compran.

Formulación correcta: las herramientas son necesarias y no suficientes. La proporción sana en una PYME es aproximadamente un tercio herramientas, un tercio configuración y proceso, un tercio personas.

Este ya lo desmontamos en 01-04 con la cadena del ataque oportunista. Añadimos aquí los cuatro argumentos que lo cierran definitivamente:

1. El escaneo es masivo, barato y continuo. Escanear el espacio completo de direcciones IPv4 en busca de un puerto concreto es cuestión de horas y de un coste ridículo. Una IP pública recién asignada empieza a recibir sondeos automatizados en cuestión de minutos. Nadie decidió atacar a Nimbus: un programa encontró un puerto.
2. La rentabilidad favorece a los pequeños. Una gran empresa tiene equipo de seguridad, presupuesto y detección. Una PYME tiene datos valiosos, dependencia total de sus sistemas y muchas menos defensas. Para un grupo de ransomware que actúa a escala, cien víctimas pequeñas y mal defendidas son mejor negocio que una grande y bien defendida.
3. Las PYMES son la puerta de entrada a las grandes. Nimbus da servicio a clínicas y academias, y tiene acceso remoto de una consultora. Un atacante que quiera llegar a un cliente concreto puede entrar por el proveedor. Es el patrón de la cadena de suministro que analizaremos en 02-06 con casos reales.
4. El impacto relativo es mayor. Una gran empresa absorbe una parada de tres días. Nimbus, con un SaaS del que dependen agendas de clínicas en marcha, no puede: cada hora de parada son clínicas que no pueden atender y contratos que no se renuevan.

Conclusión del mito 3: la pregunta correcta no es «¿somos interesantes?», sino «¿somos alcanzables y explotables?». La primera pregunta la responde el ego; la segunda, un escáner.

Con el vocabulario y los modelos ya colocados, este es el recorrido de las cinco lecciones que vienen, articulado sobre la Kill Chain:

• 02-02 recorre los ataques técnicos ordenados por fase de la cadena.
• 02-03 se detiene en la ingeniería social, que es la fase de entrega dominante en incidentes reales.
• 02-04 presenta el catálogo de defensas que contrarresta lo anterior, capa a capa.
• 02-05 profundiza en identidad y control de acceso, porque cuando el perímetro se difumina la identidad es el nuevo perímetro.
• 02-06 analiza incidentes reales y cierra con un caso completo de Nimbus.

Errores comunes:

• Adoptar un marco entero de golpe. Intentar implantar los 18 controles de CIS o certificarse en ISO 27001 en un trimestre garantiza el abandono. Los marcos se usan por partes y de forma iterativa.
• Confundir marco con producto. Ningún fabricante «te da» el NIST CSF. El marco organiza tu trabajo; las herramientas cubren partes concretas.
• Concentrar todo el esfuerzo en Proteger. Es el reparto más común y el más desequilibrado. Detectar y Responder son las funciones que deciden el tamaño del daño.
• Copiar el organigrama de una empresa grande. Nimbus no necesita un SOC ni un CISO a tiempo completo; necesita que las funciones tengan dueño, aunque el dueño haga tres cosas más.
• Usar la Kill Chain como si fuera lineal y estricta. Los atacantes iteran, retroceden y saltan fases. El modelo es una herramienta de razonamiento, no una descripción literal.
• Creer que ATT&CK hay que aprendérselo. Es un catálogo de consulta. Se usa por técnicas concretas y relevantes para tu entorno, no de memoria.
• Tratar los mitos como un problema de ignorancia ajena. Los mitos sobreviven porque son cómodos: permiten no gastar, no cambiar procesos y no asumir responsabilidad.

Consejos:

• Haz la tabla del apartado 3 para tu organización real, con las seis funciones y una columna de «situación honesta». Es el mejor diagnóstico por hora invertida que existe.
• Asigna un dueño nominal a cada dominio del apartado 2, aunque sea la misma persona en varios. Un dominio sin nombre propio es un dominio sin defensa.
• Cuando evalúes una medida nueva, pregúntate en qué fase de la cadena actúa. Si todas tus medidas actúan en la misma fase, tienes una defensa gruesa y frágil.
• Reserva tiempo de seguridad en el calendario, no en las intenciones. Lo que no está agendado no ocurre en una empresa de 38 personas.
• Empieza a leer ATT&CK por una sola táctica —Initial Access— y compárala con la superficie de ataque que mediste en 01-04.

Con la información acumulada en el módulo 1 (inventario A-01…A-22, hallazgos del descubrimiento, modelado STRIDE), sitúa cada uno de estos siete hechos en la función del CSF que resulta afectada, indica si es una carencia o un punto fuerte, y propón una acción concreta de mejora.

1. El python -m http.server llevaba 94 días corriendo y nadie se dio cuenta.
2. El rol nimbus_api no tiene permiso de DELETE ni acceso a la tabla de nóminas.
3. Existen copias de seguridad del bucket nimbus-backups-prod, pero nunca se ha probado una restauración completa.
4. Nadie sabe a quién habría que llamar si a las 3 de la madrugada se cifran los servidores.
5. La consultora externa tiene acceso remoto administrativo permanente, sin fecha de caducidad y sin contrato que detalle qué puede hacer.
6. Los adjuntos se sirven mediante URLs firmadas que caducan a los 120 segundos.
7. El grupo de seguridad tenía el puerto 22 abierto a 0.0.0.0/0 y se descubrió por casualidad al revisar el inventario.

Marta te pide que le propongas un reparto formal de responsabilidades de seguridad entre las cinco personas del equipo directivo y técnico (Marta, Iván, Lucía, Rubén y Sara), sabiendo que nadie puede dedicar más de un 10 % de su tiempo a seguridad. Para cada uno de los diez dominios del apartado 2, indica: responsable principal, qué haría concretamente en su 10 % y qué se externaliza.

Justifica además una decisión difícil: ¿quién debería ser el responsable último de seguridad de Nimbus y por qué?

Un atacante ejecuta la siguiente secuencia contra Nimbus:

1. Encuentra en un repositorio público de GitHub un fichero de configuración antiguo subido por error, con el nombre del subdominio interno admin-old.nimbusreservas.example.
2. Comprueba que ese subdominio sigue resolviendo y que sirve un panel de administración obsoleto sin MFA.
3. Prueba en él una lista de contraseñas filtradas de otras brechas con los correos del equipo, encontrados en perfiles profesionales públicos.
4. Entra con una cuenta antigua de un empleado que se fue hace un año y que nadie desactivó.
5. Desde ese panel, extrae un token de API con permisos amplios.
6. Usa el token contra la API de producción para exportar datos de clientes durante tres semanas, en lotes pequeños.

Se pide: (a) asigna cada paso a su fase de la Kill Chain; (b) para cada paso, indica una medida que lo habría roto; (c) señala en qué paso habría sido más barato romperlo y en cuál habría sido más probable detectarlo.

Solución 1

Lectura del conjunto: los dos puntos fuertes están ambos en Proteger, y las carencias graves en Detectar, Responder y Gobernar. Nimbus es un caso de manual del desequilibrio descrito en el apartado 3: sabe construir defensas, pero no sabe si están funcionando ni qué hacer cuando fallen.

Solución 2

La decisión difícil. El responsable último debe ser Marta (CTO), y no Lucía, por tres razones: (a) la seguridad implica aceptar riesgos, y aceptar un riesgo es una decisión de negocio que requiere autoridad, no conocimiento técnico; (b) si el responsable es quien administra los sistemas, se juzga a sí mismo —se rompe la separación de funciones de 01-03—; (c) las decisiones más importantes pendientes (contrato de la consultora, presupuesto, política, comunicación a clientes) no son técnicas. Lucía es la responsable operativa; Marta, la responsable última. Y conviene escribirlo, porque una responsabilidad que no está escrita se diluye en cuanto hay presión de entrega.

Solución 3

(c) Dónde romperlo:

• Más barato: el paso 2. Borrar un registro DNS obsoleto cuesta un minuto y no requiere ninguna herramienta. Sin ese subdominio, los pasos 3 a 6 no existen. Es la ilustración perfecta de por qué reducir superficie es la inversión más rentable.
• Más probable de detectar: el paso 3 y el paso 6. Una ráfaga de intentos de autenticación fallidos contra un panel es una señal muy visible en cualquier log; una exportación sostenida y anómala durante tres semanas también lo es, si alguien mira. Que el ataque durase tres semanas no indica sofisticación del atacante: indica ausencia de la función Detectar.

Observación final: ninguno de los seis pasos requiere una vulnerabilidad de software ni un exploit. Todo el ataque se apoya en higiene: un fichero subido por error, un subdominio olvidado, contraseñas reutilizadas, una baja mal ejecutada y un token permanente. Es la forma habitual de los incidentes reales, y la razón por la que los básicos rinden desproporcionadamente.

Ya sabes qué terreno pisas. La ciberseguridad se distingue por su objeto: un adversario que se adapta, y de ahí que sea una disciplina antagónica y evolutiva en lugar de un estado que se alcanza. Has visto que se organiza en dominios —redes, aplicaciones, dato, identidad, operaciones, nube, física, factor humano, continuidad y gobierno— y que en una empresa de 38 personas cada dominio no es un equipo sino una responsabilidad con nombre propio; lo que no puede pasar es que un dominio se quede sin dueño. El NIST Cybersecurity Framework te ha dado el índice con sus seis funciones —Gobernar, Identificar, Proteger, Detectar, Responder y Recuperar— y, aplicado a Nimbus, ha producido un diagnóstico incómodo pero útil: lo que falta no son mejores defensas, sino la capacidad de saber si funcionan y de reaccionar cuando fallen. Junto a él has colocado CIS Controls como lista de tareas, ATT&CK como examen de detección e ISO 27001 como prueba ante terceros.

Has aprendido el vocabulario de equipos —Blue, Red, Purple, SOC y CSIRT— y, más importante, su traducción realista: no hace falta un centro de operaciones, hace falta que ninguna de esas funciones esté a cero. Y has incorporado el modelo que estructura todo lo que viene: el ciclo de vida de un ataque, con sus siete fases de la Kill Chain y su equivalencia con las tácticas de ATT&CK, junto con la idea que lo hace valioso para el defensor: no necesitas ganar en todas las fases, basta con romper una, y cuanto antes la rompas, más barato sale. Por último has desmontado los tres mitos que dejan huecos concretos: que la seguridad es cosa de IT, que basta con un antivirus y un cortafuegos, y que a una empresa pequeña no la ataca nadie —cuando la pregunta correcta no es si eres interesante, sino si eres alcanzable.

Con el mapa completo, toca mirar de cerca al adversario. En la siguiente lección, Tipos de Ataques Cibernéticos (02-02), recorreremos los ataques técnicos ordenados por las fases de la cadena que acabas de aprender: reconocimiento, ataques a la red, ataques a credenciales, los diez fallos más frecuentes de aplicaciones web —incluido el IDOR que ya corregiste en 01-01—, ransomware con doble extorsión, cadena de suministro y abuso de APIs. Cada uno con su ejemplo mínimo sobre la arquitectura de Nimbus, su señal de detección y la defensa que lo neutraliza.