Las dos lecciones anteriores han sido un inventario del problema: los ataques técnicos ordenados por fase de la cadena y el vector humano con toda su casuística. Esta lección es el inventario de la respuesta. Vamos a recorrer el catálogo de defensas que contrarresta lo visto, organizado por las capas de la defensa en profundidad que estableciste en 01-03: perímetro y red, endpoint, dato, aplicación y ciclo de desarrollo, y registro y observabilidad. De cada medida verás qué hace, cuándo se usa y qué ataque concreto neutraliza; la implementación detallada corresponde al módulo 5 y aquí solo se enlaza. Y como el presupuesto de Nimbus no es infinito, la lección termina con lo más útil de todo: una tabla de las doce medidas de mayor retorno con su coste, esfuerzo e impacto, y un plan por fases de 30, 90 y 180 días que Marta podría aprobar el lunes.

1. Cómo elegir defensas: tres criterios antes de gastar un euro
2. Protección del perímetro y de la red
3. Protección del endpoint
4. Protección del dato
5. Protección de la aplicación y del ciclo de desarrollo
6. El registro y la observabilidad como medida de protección
7. Priorizar con presupuesto de PYME: las 12 medidas de mayor retorno
8. Plan por fases: 30, 90 y 180 días

Antes del catálogo, el método. La forma más habitual de gastar mal en seguridad es comprar lo que se anuncia y no lo que falta.

Criterio 1: ¿qué ataque concreto neutraliza? Toda medida debe poder asociarse a una entrada de la tabla resumen de 02-02 o del catálogo de 02-03. Si no sabes qué ataque para, no sabes si te hace falta.

Criterio 2: ¿en qué fase de la cadena actúa y qué otras capas tengo ahí? Recuerda la Kill Chain de 02-01: si todas tus medidas actúan en la misma fase, tienes una defensa gruesa por un lado y desnuda por el otro.

Criterio 3: ¿qué tipo de control es? Los controles se clasifican por función, y una defensa sana tiene de los cuatro tipos:

El desequilibrio típico ya lo diagnosticaste con el NIST CSF en 02-01: casi todo preventivo, casi nada detectivo. Es cómodo porque lo preventivo se compra e instala una vez, mientras que lo detectivo exige que alguien mire. Pero cuando la prevención falla —y fallará— lo único que limita el daño es la detección.

Un cuarto criterio, informal pero decisivo en una PYME: ¿esta medida sobrevive a un mal día? Una defensa que exige diez minutos diarios de disciplina de alguien saturado no durará tres semanas. Las medidas que funcionan en Nimbus son las que están por defecto, automatizadas o en el camino natural del trabajo.

El perímetro clásico ha perdido peso —la mitad de la plantilla trabaja en remoto y los datos están en la nube— pero no ha desaparecido: sigue siendo la primera línea contra el escaneo masivo de 02-02.

Sobre el WAF, con precisión, porque es la medida más malinterpretada de todas: un WAF compra tiempo, no corrige código. Es extraordinariamente útil para tres cosas: frenar el ruido de fondo automatizado, aplicar un parche virtual mientras se corrige una vulnerabilidad recién descubierta, y aportar visibilidad de lo que se intenta contra la API. Lo que no hace: sustituir a las consultas parametrizadas ni detectar un IDOR, porque una petición IDOR está perfectamente bien formada. Si Nimbus instala un WAF y con ello relaja la revisión de código, ha empeorado.

Qué es. Dividir la red en zonas con control entre ellas, de modo que comprometer una no dé acceso a las demás.

Por qué es la medida más rentable contra el ransomware. La cronología de 02-02 mostraba que el atacante pasa días moviéndose lateralmente. La segmentación es lo que convierte «entraron en un portátil» en «entraron en un portátil» y no en «cifraron toda la infraestructura». Tres reglas prácticas para Nimbus:

• La wifi de invitados no toca nada interno. Es un control de cinco minutos en el router y elimina una clase entera de riesgo.
• La zona de datos solo acepta conexiones de la zona de aplicación. Nunca desde la oficina ni desde Internet. Esto ya lo comprobaste con describe-security-groups en 01-04.
• El acceso administrativo pasa siempre por un punto único (bastión o VPN con MFA), que es el único sitio donde hay que vigilar de verdad.

Contra el volumétrico, la defensa se contrata: el proveedor cloud o una CDN absorben el tráfico antes de que llegue al enlace de Nimbus. Es una de las pocas defensas que realmente no se puede construir con recursos propios, porque requiere capacidad de red.

Contra el aplicativo, la defensa se programa, y ya la viste en 02-02: paginación obligatoria, límites de rango de negocio, límite de tasa y tiempo máximo de consulta. Ningún servicio anti-DDoS distingue una petición cara de una barata: para él, ambas son una petición HTTPS legítima.

Con 19 personas fuera de la oficina, el acceso remoto es el perímetro de Nimbus.

Recomendación para Nimbus: MFA obligatorio en el acceso remoto (sin excepciones, incluida la consultora), bastión con registro de sesión para el acceso administrativo, y acceso just-in-time con caducidad para terceros en lugar del acceso permanente actual del activo A-19. El detalle de identidad va en 02-05; la configuración de red, en 05-04.

Los 40 portátiles (A-14) son donde trabajan las personas, y por tanto donde aterriza el phishing de 02-03.

Por qué importa la diferencia en el caso de Nimbus. Repasa el ejercicio 3 de 02-03: el portátil de Rubén ejecuta un componente que establece un canal saliente y roba la cookie del navegador. Un antivirus de firmas puede no ver nada, porque el fichero es nuevo y porque buena parte de la actividad usa herramientas legítimas del sistema. Un EDR ve el patrón: un proceso ofimático lanzando un intérprete de comandos, un acceso al almacén de credenciales del navegador, una conexión saliente a un dominio recién registrado. Y, sobre todo, permite aislar el equipo con un clic y reconstruir después qué pasó.

La advertencia realista: un EDR cuyas alertas nadie mira es un gasto, no una defensa. Antes de comprarlo hay que decidir quién lo atiende y cuándo. Para Nimbus, la opción sensata suele ser un EDR con servicio gestionado de vigilancia, o un EDR bien configurado con pocas alertas y muy accionables.

La medida más infravalorada de las tres es el parcheo. No es vistosa, no se puede enseñar a un cliente y no aparece en ningún folleto comercial. Pero dos de los mayores incidentes de la historia reciente —los que analizaremos en 02-06— fueron vulnerabilidades conocidas y con parche disponible durante meses. El hardening y la gestión del endpoint en detalle se estudian en 05-06.

Las capas anteriores protegen contenedores. Esta protege lo que hay dentro, y es la única que sigue sirviendo cuando las demás fallan.

No se puede proteger de forma diferenciada lo que no está clasificado. Ya lo hiciste en 01-04 con los cuatro niveles (público, interno, confidencial, restringido) y sus tres reglas: herencia hacia arriba, agregación que sube el nivel y contexto que define la sensibilidad. La clasificación no es una medida en sí misma: es lo que hace posible aplicar el resto sin arruinarse.

Dos precisiones que evitan falsas sensaciones de seguridad:

1. El cifrado en reposo del proveedor protege contra el robo del medio físico, no contra un atacante con credenciales válidas. Si el atacante tiene acceso a la base de datos, el motor le devuelve los datos descifrados: para eso está la clave. No protege contra el IDOR ni contra el ransomware operado con credenciales robadas.
2. La clave es el activo real. Cifrar con una clave que está en el mismo sitio que el dato es un ejercicio decorativo. La gestión de claves —dónde viven, quién accede, cómo se rotan— es el problema difícil, y se estudia en 03-06.

Los mecanismos criptográficos se desarrollan en el módulo 3; aquí interesa dónde aplicarlos.

Es la medida más importante de toda la lección, porque es la única que devuelve el negocio cuando todo lo demás ha fallado.

La regla 3-2-1:

• 3 copias de los datos (la de producción y dos más).
• En 2 soportes o tecnologías distintas.
• 1 de ellas fuera del alcance de la infraestructura principal.

La ampliación moderna, 3-2-1-1-0, que es la que importa contra el ransomware:

• 1 copia inmutable o desconectada.
• 0 errores en la prueba de restauración.

Por qué la inmutabilidad es la pieza decisiva. Recuerda la cronología del ransomware de 02-02: el día 20, antes de cifrar, el atacante borra las copias. Si las copias de Nimbus están en el bucket nimbus-backups-prod (A-03), dentro de la misma cuenta cloud (A-05) y accesibles con las mismas credenciales que producción, entonces no son copias: son ficheros más que se van a cifrar.

Configuración objetivo para Nimbus:

La frase que conviene interiorizar: una copia que no se ha restaurado nunca no es una copia, es una esperanza. El caso más común de fracaso no es que falte la copia: es que la copia existía, estaba corrupta, incompleta o nadie sabía el procedimiento. La continuidad y los objetivos de tiempo de recuperación se desarrollan en 04-06.

La minimización es la medida con mejor relación coste/beneficio del apartado, y casi nunca se aplica porque exige decir que no a datos que «algún día podrían ser útiles». Un dato que no existe no se filtra, no se cifra, no se audita y no aparece en una notificación de brecha.

Nota sobre implicaciones legales: minimización, seudonimización, plazos de retención y borrado tienen exigencias normativas concretas, especialmente cuando los datos pueden revelar información de salud como ocurre con las agendas de las clínicas. Las decisiones deben validarse con el responsable de cumplimiento o con asesoría jurídica; el tratamiento se aborda en 06-03.

La API (A-04) es la superficie principal de Nimbus. Esta capa desplaza la seguridad hacia la izquierda: al momento de escribir el código, donde corregir es barato.

La lista de comprobación de cuatro preguntas que Iván debería aplicar en cada revisión, ya introducida en 02-02:

1. ¿Quién eres? — ¿el endpoint exige autenticación?
2. ¿Es tuyo? — ¿se filtra por tenant_id y se verifica la propiedad del recurso?
3. ¿Es válido lo que envías? — ¿hay validación de tipos y de rangos?
4. ¿Cuánto cuesta esto? — ¿hay paginación, límites y límite de tasa?

El hallazgo del token sin caducidad de 01-04 y el .env filtrado del ataque encadenado de 02-02 tienen la misma raíz: los secretos viven donde no deben.

Un conjunto de instrucciones al navegador que cuesta unos minutos configurar y neutraliza clases enteras de ataque del apartado 6 de 02-02.

Explicación de cada una, y qué ataque para:

Detalles de la CSP que marcan la diferencia:

• default-src 'none' como base. Se parte de «nada permitido» y se abre lo estrictamente necesario. Es el principio de seguro por defecto de 01-03 aplicado al navegador.
• Sin 'unsafe-inline' ni 'unsafe-eval'. Permitirlos anula la mayor parte del valor de la CSP frente a XSS. Exige que el JavaScript esté en ficheros, no incrustado.
• report-uri convierte la CSP en un control detectivo: cada violación se registra. Un pico de informes de CSP suele ser la primera señal de un intento de XSS. Conviene desplegarla primero en modo solo informe (Content-Security-Policy-Report-Only) para no romper la SPA.

Ya ha aparecido en cada apartado, y por una razón: es la medida que quita rentabilidad a la mayoría de los ataques automatizados —fuerza bruta, enumeración, exportación masiva, DDoS aplicativo, abuso de lógica de negocio.

Los detalles de AppSec se desarrollan en 05-05.

Este es el fichero que Iván añadiría al repositorio de Nimbus. Está explicado paso a paso después.

Las siete decisiones de este fichero, explicadas:

1. permissions: contents: read. Por defecto, muchos flujos reciben permisos amplios. Declarar el mínimo evita que una acción comprometida escriba en el repositorio. Es mínimo privilegio (01-03) aplicado al CI.
2. Acciones fijadas por hash de commit, no por @v4. Una etiqueta puede reapuntarse a otro código; un hash, no. Es la defensa contra el ataque a la cadena de suministro de 02-02.
3. fetch-depth: 0. Sin el historial completo, el análisis de secretos solo mira el último commit y se pierde exactamente lo que hay que encontrar: la credencial que alguien subió y «borró» hace ocho meses.
4. --strict en el análisis de dependencias. Sin él, el informe se genera y nadie lo lee. Con él, la construcción falla y hay que decidir: actualizar o justificar la excepción por escrito. Un análisis que no puede bloquear no cambia comportamientos.
5. -ll en el análisis estático. Filtrar por severidad es lo que evita el destino habitual de estas herramientas: 400 avisos, nadie los mira, se desactiva la herramienta.
6. SBOM. Cuando salga la próxima vulnerabilidad crítica en una librería famosa, la pregunta será «¿nos afecta?». Con SBOM se responde en minutos; sin él, en días. Es el inventario de 01-04 aplicado al software.
7. if: always() al guardar resultados. Los informes del día en que algo falla son precisamente los que hay que conservar.

Y una advertencia sobre qué NO hace este flujo: no encuentra el IDOR, no encuentra el abuso de lógica de negocio y no encuentra un fallo de diseño de autorización. Las herramientas automáticas cubren los patrones conocidos; el criterio humano cubre el resto. Complementarios, no sustitutivos.

El diagnóstico del CSF en 02-01 fue claro: la función más débil de Nimbus es Detectar. Y sin registro no hay detección posible.

Los cinco campos que debe tener todo evento útil: cuándo (con zona horaria y reloj sincronizado), quién (identidad nominal, no «admin»), qué (acción concreta), sobre qué (recurso y tenant) y desde dónde (IP y agente). Un log sin actor identificable no sirve para investigar; un log sin recurso no sirve para medir el alcance.

Este apartado es tan importante como el anterior, porque un registro mal diseñado crea un problema de seguridad en lugar de resolverlo.

Por qué esta versión permite detectar y la anterior no: el campo num_registros junto con sesion_id y tenant_id es exactamente lo que hacía funcionar la consulta de detección del ejercicio 3 de 02-02. La detección se diseña cuando se escribe el log, no cuando ocurre el incidente. Y el log correcto contiene menos datos personales que el incorrecto, no más.

1. Centralizado. Logs repartidos por cinco máquinas no se correlacionan. Además, un atacante que compromete una máquina borra sus logs locales: enviarlos fuera en tiempo real es lo que preserva la evidencia.
2. Íntegro y con retención. La tabla de auditoría append-only de 01-01 —con INSERT pero sin UPDATE ni DELETE para nimbus_api— es la aplicación de esta idea. Retención mínima recomendable: 90 días en caliente, un año en frío. Muchas brechas se descubren meses después, y sin logs no se puede determinar el alcance, que es justo lo que hay que comunicar a clientes y autoridades.
3. Con alertas que alguien atiende. Un registro sin alertas es un archivo histórico. Pocas alertas y muy buenas: para Nimbus, cinco reglas iniciales bastan.

Las cinco alertas con las que empezar mañana:

Las técnicas de monitorización y detección se desarrollan en 05-02.

Nimbus no puede hacerlo todo. Esta es la tabla que convierte el catálogo en decisiones. Coste es dinero, esfuerzo es tiempo del equipo, impacto es reducción real de riesgo.

Tres observaciones sobre esta tabla:

• Ocho de las doce medidas tienen coste económico nulo o bajo. Lo que falta en Nimbus no es presupuesto: es decisión y tiempo asignado. Es la conclusión más repetida en seguridad de PYMES y la que más cuesta aceptar.
• La única con coste medio real es el EDR (#12), y va la última a propósito: sin MFA, sin copias inmutables y sin registro, un EDR es un lujo mal colocado.
• Ninguna de las doce es un producto de seguridad perimetral. No hay ningún cortafuegos nuevo en la lista, y no es un olvido: el riesgo de Nimbus no está ahí.

Todo lo que se puede hacer sin presupuesto, sin proveedor y sin proyecto.

Cómo se sostiene esto en el tiempo: revisión trimestral de una hora buscando lo que sobra (01-04), un simulacro por trimestre, una prueba de restauración por trimestre y una recertificación de accesos por semestre. Cuatro rutinas, todas en el calendario. Lo que no está agendado, no ocurre.

Nota: los plazos de este plan son orientativos y deben ajustarse a la realidad de cada organización. Las obligaciones formales de política, control documentado y evidencia auditable se tratan en 04-02, 04-03 y 06-04.

Errores comunes:

• Comprar antes de cerrar. Adquirir un WAF o un EDR mientras el SSH está abierto a Internet es invertir en el tejado con los cimientos sin hacer.
• Confiar en el WAF para no corregir el código. El WAF compra tiempo; no arregla una inyección y no ve un IDOR.
• Llamar copia a algo que no se ha restaurado. El fallo más común no es la ausencia de copias, sino su inutilidad en el momento de la verdad.
• Guardar las copias en la misma cuenta y con las mismas credenciales que producción. El ransomware moderno las busca y las borra: eso no es una copia.
• Registrar el cuerpo completo de las peticiones. Convierte el sistema de logs en un almacén de tokens y datos personales, y multiplica el impacto de cualquier fuga.
• Generar cien alertas que nadie mira. Peor que no tener alertas, porque produce sensación de cobertura.
• Desplegar CSP directamente en modo bloqueo. Rompe la SPA y acaba desactivada para siempre. Modo informe primero.
• Dejar el análisis del CI sin capacidad de bloquear. Un informe que no para nada no cambia el comportamiento de nadie.
• Cifrar y darlo por resuelto. El cifrado en reposo no protege contra credenciales robadas ni contra un fallo de autorización.
• Escribir el plan sin dueño ni fecha. Una tarea sin nombre y sin día es una intención.

Consejos:

• Empieza siempre por el punto 3 de la tabla: cerrar lo que ya está abierto. Coste cero, impacto máximo, y además reduce el trabajo futuro.
• Para cada medida que implantes, escribe cómo comprobarías que sigue funcionando dentro de seis meses. Las defensas se degradan en silencio.
• Prefiere lo que funciona por defecto frente a lo que exige disciplina diaria. En una empresa de 38 personas, la disciplina se agota; la configuración permanece.
• Cuando dudes entre dos medidas, elige la que reduzca el daño de un fallo frente a la que intente evitar un fallo más. La primera funciona incluso cuando te equivocas.
• Convierte cada incidente y cada simulacro en una alerta nueva. Es el purple team de coste cero de 02-01.
• Revisa el plan de fases con Marta cada 30 días, marcando lo hecho y renegociando lo que no. Un plan que no se revisa muere en la fase 1.

Para cada uno de estos ocho ataques de las lecciones 02-02 y 02-03, indica: la medida principal que lo neutraliza, una segunda capa independiente de la primera, el tipo de control de cada una (preventivo, detectivo, correctivo o disuasorio) y la fase de la cadena en la que actúan.

1. Password spraying contra las cuentas del equipo.
2. Inyección SQL en el buscador de clientes.
3. Ransomware que cifra la infraestructura y borra las copias.
4. Fraude de cambio de IBAN de un proveedor, enviado a Sara.
5. Exfiltración lenta de datos mediante un token robado.
6. XSS almacenado en el campo «notas» de una reserva.
7. SSRF a través de la URL del logotipo de una clínica.
8. Acción de CI de terceros comprometida.

Este es el código de registro actual de la API de Nimbus:

Se pide: (a) identifica los problemas de cada línea marcada y explica el riesgo concreto de cada uno; (b) reescribe el código con un registro correcto; (c) indica qué tres alertas podrías construir sobre el registro corregido y qué ataque detectaría cada una; (d) explica por qué el registro correcto contiene menos datos personales que el incorrecto y aun así permite detectar más.

Marta te da 6.000 € anuales y un día a la semana de tiempo del equipo para seguridad durante el primer semestre. Un comercial le ha ofrecido un paquete de 5.500 € que incluye un cortafuegos de nueva generación para la oficina de Valencia y un antivirus para los 40 portátiles.

Se pide:

1. Argumenta, con datos de las lecciones del módulo, por qué esa compra no es la mejor asignación del presupuesto de Nimbus.
2. Propón tu asignación alternativa de los 6.000 € y del día semanal, con partidas concretas.
3. Identifica las tres medidas de coste cero que deberían hacerse en las dos primeras semanas, y justifica el orden.
4. Explica qué riesgo aceptas conscientemente al no gastar en perímetro, y cómo lo comunicarías a Marta por escrito.
5. Define tres indicadores que presentarías a los seis meses para demostrar que la inversión ha servido.

Solución 1

Patrón que emerge: en los ocho casos, la segunda capa es de naturaleza distinta a la primera —si la primera es de código, la segunda es de configuración o de detección—. Eso es defensa en profundidad bien entendida: capas que no fallan por la misma causa. Dos capas que dependen de que Iván recuerde algo son, en la práctica, una sola capa.

Solución 2

(a) Problemas de cada línea:

(b) Código corregido:

Tres decisiones que merecen comentario:

• email_hash en lugar del correo en los fallos. Permite correlacionar intentos contra la misma cuenta sin acumular un listado de correos válidos en los logs. Es minimización aplicada a la detección.
• jti en lugar del token. El jti es el identificador del token: sirve para correlacionar la sesión y para revocarla, pero no permite suplantar a nadie. Se detalla en 02-05.
• Mensaje de error uniforme. «Credenciales incorrectas» tanto si el correo no existe como si la contraseña falla: evita la enumeración de usuarios de 02-02.

(c) Tres alertas construibles:

(d) Por qué menos datos permiten detectar más. El registro incorrecto acumula contenido (contraseñas, tokens, nombres de pacientes) que no sirve para detectar nada: nadie construye una alerta sobre el nombre de un paciente. El registro correcto acumula metadatos estructurados —quién, qué, cuánto, desde dónde— que son exactamente sobre lo que se consulta y se agrega. La consecuencia es doble y muy elegante: se detecta más y se reduce el impacto de una fuga de los propios logs, que dejan de ser un objetivo valioso. Registrar bien es simultáneamente una mejora de detección y una medida de protección de datos.

Solución 3

1. Por qué la compra propuesta no es la mejor asignación. Cuatro argumentos, apoyados en el módulo:

• No ataca el riesgo real de Nimbus. La superficie principal es la API en la nube y las identidades, no la red de la oficina de Valencia. Un NGFW en la oficina no protege ni a los 19 empleados en remoto, ni la cuenta cloud (A-05), ni la API, ni los buckets.
• Un antivirus de firmas no cubre lo que ocurre. Repasa la tabla del mito 2 en 02-01: no para el phishing de credenciales, ni el IDOR, ni el bucket mal configurado, ni la credencial de la consultora sin MFA, ni el fraude del CEO.
• Consume el 92 % del presupuesto dejando sin financiar las medidas 1 a 8 de la tabla del apartado 7, que tienen impacto muy alto y coste bajo o nulo.
• Nimbus tiene hoy problemas conocidos y sin resolver —SSH abierto, Redis sin autenticación, token permanente, copias sin probar, cero detección— que ninguna de las dos piezas del paquete corrige. Gastar en lo que falta antes de cerrar lo que está abierto es el error del apartado de errores comunes.

2. Asignación alternativa:

El día semanal se reparte así: fase 1 completa en las cuatro primeras semanas (todo coste cero), después alternando implantación (registro, alertas, CI) y rutina (revisar alertas, parchear, revisión trimestral de lo que sobra).

3. Las tres medidas de coste cero de las dos primeras semanas, en orden:

1. Cerrar la superficie expuesta (SSH 0.0.0.0/0, Redis sin autenticación, http.server, node_exporter, snmpd). Va primera porque es explotable ahora mismo por un bot sin que nadie decida atacar a Nimbus: es riesgo activo, no potencial.
2. MFA en todas las cuentas administrativas, incluida la consultora. Va segunda porque neutraliza de golpe spraying, stuffing y la mayor parte del phishing de credenciales, que es el vector dominante.
3. Rotar el token permanente y poner caducidad a todos los tokens. Va tercera porque cierra el eslabón 2 del ataque encadenado de 02-02, y porque un token filtrado convierte el MFA en irrelevante.

4. El riesgo que se acepta y cómo comunicarlo. Al no invertir en perímetro de oficina se acepta un riesgo residual sobre la red local de Valencia: un dispositivo comprometido en la oficina tendría más libertad de movimiento de la deseable. Se mitiga parcialmente y sin coste con segmentación en el router existente (invitados aislados, zona de datos cerrada) y con el EDR en los portátiles.

La comunicación a Marta debe ser escrita, explícita y fechada:

«Riesgo aceptado (fecha, revisión en 6 meses): no se refuerza el perímetro de la oficina de Valencia en este semestre. Motivo: el 100 % de los datos de clientes está en la nube y la mitad de la plantilla trabaja fuera de la oficina, por lo que el perímetro físico no es el vector principal. Mitigación aplicada: segmentación con el equipamiento actual, EDR en todos los portátiles y cifrado de disco. Se revisará si cambia la arquitectura o si crece la plantilla en oficina. Aprobado por: Marta Solves.»

Esto no es burocracia: es la diferencia entre aceptar un riesgo (decisión consciente, documentada, revisable) e ignorarlo (que es lo que se descubre después de un incidente). La formalización de este proceso se estudia en 04-01.

5. Tres indicadores a los seis meses:

Un cuarto indicador muy visual para dirección: número de servicios expuestos a Internet, que debería bajar de seis a uno en el primer mes. Es el que mejor comunica el progreso a alguien no técnico.

Tienes el catálogo de la respuesta. Has aprendido primero el método para elegir: qué ataque concreto neutraliza cada medida, en qué fase de la cadena actúa, de qué tipo de control se trata —preventivo, detectivo, correctivo o disuasorio— y si sobrevivirá a un mal día en una empresa de 38 personas. En perímetro y red has visto los tipos de cortafuegos y la precisión que evita el error más caro: un WAF compra tiempo y da visibilidad, pero no corrige código ni ve un IDOR; has entendido la segmentación como la medida más rentable contra el movimiento lateral, la doble naturaleza de la defensa anti-DDoS —volumétrica que se contrata, aplicativa que se programa— y la evolución del acceso remoto desde la VPN de todo o nada hacia el acceso just-in-time con caducidad. En endpoint has distinguido antivirus de EDR por lo que de verdad los separa —comportamiento, telemetría y capacidad de aislar— y has colocado el parcheo en su sitio: la medida menos vistosa y una de las que más incidentes graves habría evitado.

En protección del dato te llevas tres ideas que sostienen todo lo demás: que el cifrado en reposo no protege contra credenciales válidas y que la clave es el activo real; que la regla 3-2-1 ampliada con inmutabilidad y prueba de restauración es la única defensa que devuelve el negocio cuando todo ha fallado, porque el ransomware moderno busca y borra las copias; y que la minimización es la medida con mejor relación coste/beneficio, porque lo que no existe no se filtra. En aplicación y ciclo de desarrollo has recorrido la revisión de código con sus cuatro preguntas, la gestión de secretos con su regla de rotar primero e investigar después, las cabeceras HTTP con una CSP construida desde default-src 'none', el límite de tasa como quitarrentabilidad universal, y un flujo de CI real cuyas siete decisiones —permisos mínimos, acciones fijadas por hash, historial completo, análisis que bloquea, filtrado por severidad, SBOM y conservación de informes— convierten un informe decorativo en un control efectivo.

En registro y observabilidad has aprendido qué registrar, con sus cinco campos imprescindibles, y sobre todo qué no registrar nunca; y has comprobado en el ejercicio la conclusión más contraintuitiva de la lección: el registro correcto contiene menos datos personales que el incorrecto y permite detectar mucho más, porque la detección se construye sobre metadatos estructurados, no sobre contenido. Y has terminado con lo más útil para una PYME: las doce medidas de mayor retorno —ocho de ellas con coste económico nulo o bajo, ninguna de ellas un producto perimetral— y un plan de 30, 90 y 180 días con dueño y verificación para cada tarea, sostenido por cuatro rutinas trimestrales en el calendario.

De esas doce medidas, la número uno era el MFA, y varias de las restantes giran alrededor de lo mismo: quién eres y qué puedes hacer. No es casualidad. Cuando el perímetro se difumina —nube, remoto, terceros, móviles— la identidad se convierte en el nuevo perímetro. En la siguiente lección, Identidad, Autenticación y Control de Acceso (02-05), la estudiaremos a fondo: el ciclo de vida de una identidad y las cuentas huérfanas, qué dicen hoy las guías sobre contraseñas, las formas de MFA ordenadas por resistencia al phishing, SSO y los protocolos de identidad con la diferencia exacta entre OAuth 2.0 y OpenID Connect, sesiones y JWT con su validación correcta frente a la ingenua, los modelos de autorización DAC, MAC, RBAC, ABAC y ReBAC con el diseño concreto de Nimbus, y las cuentas privilegiadas, el acceso just-in-time y la recertificación.