La lección anterior cerró con una pieza pendiente: todo lo que hemos construido presupone que quien maneja este conocimiento lo usa bien. Pero el mismo nmap que verifica tu segmentación escanea la red de un tercero, y la misma persona capaz de encontrar un IDOR en la API de Nimbus puede encontrarlo en la de otro y no saber qué hacer con él. Esta lección es la que 05-03 dejó explícitamente aplazada: dónde está la línea legal, qué hace válida a una autorización, qué haces cuando tu empresa te pide algo que no debes hacer, y cómo se reporta —y cómo se recibe— una vulnerabilidad. Es la lección que convierte a un técnico competente en un profesional.

⚠️ Nota de validación — léela antes de seguir

Este material es formativo y no constituye asesoramiento jurídico. Los tipos penales, sus redacciones, sus penas y su interpretación jurisprudencial cambian, y la calificación de una conducta concreta depende de circunstancias que ninguna lección puede anticipar. Verifica siempre la redacción vigente del Código Penal y de la normativa citada en el BOE, y consulta con un abogado antes de tomar cualquier decisión con implicaciones legales —una prueba de seguridad, un reporte a un tercero, una negativa a una instrucción de tu empresa—. Ante la duda sobre si algo es legal: no lo hagas y pregunta.

1. La línea legal: qué dice el Código Penal español
2. Por qué la autorización lo cambia todo, y qué la hace válida
3. Lo que la gente cree que es legal y no lo es
4. Ética profesional: confidencialidad, límites y presiones
5. Sombreros blanco, negro y gris
6. Divulgación responsable: qué es y qué opciones hay
7. Cómo reportar bien una vulnerabilidad ajena
8. Cómo recibir bien un reporte: security.txt y política de divulgación
9. El circuito interno cuando llega un aviso
10. Programas de bug bounty: cuándo tienen sentido
11. CVE y coordinación: qué es un CNA
12. El dilema de la publicación y la ética de la IA en seguridad

El Código Penal español regula los delitos informáticos principalmente en los artículos 197 y siguientes —dentro de los delitos contra la intimidad— y 264 y siguientes —daños—. Lo que sigue es una explicación en lenguaje claro y orientativa, no una transcripción; verifica la redacción vigente, que ha sido modificada varias veces para transponer directivas europeas.

Cinco precisiones que evitan malentendidos frecuentes. El acceso ilícito no exige daño: basta con entrar donde no debes vulnerando una medida de seguridad, y «no rompí nada» no es una defensa. Tampoco exige gran habilidad: probar una contraseña por defecto vulnera una medida de seguridad tanto como explotar un desbordamiento de búfer. Mantenerse cuenta: si entras por error y te quedas mirando, la conducta puede seguir siendo típica. Los tipos agravados existen cuando concurren circunstancias como la organización, la afectación a infraestructuras críticas o el ánimo de lucro. Y la responsabilidad penal no es la única: puede haber responsabilidad civil, consecuencias laborales y —si hay datos personales— actuación de la autoridad de protección de datos, en vías independientes que se acumulan.

Y hay algo que no dice la ley: no existe en el ordenamiento español una eximente general de «lo hice con buena intención» ni de «era para avisarles». La intención puede influir en la valoración del caso, pero no convierte en lícito un acceso no autorizado. Esta es la asimetría que hace que el resto de la lección importe.

La misma acción técnica —escanear puertos, probar credenciales, explotar un IDOR— es un delito o un trabajo profesional según una sola variable: si existe una autorización válida. En 05-03 vimos las reglas de enfrentamiento desde el punto de vista operativo; aquí desde el jurídico.

Qué hace válida a una autorización. Cinco condiciones, y fallar en una la invalida entera:

El caso que más gente se salta: no puedes autorizar pruebas sobre sistemas de terceros. Si Nimbus contrata un pentest, Marta puede autorizar pruebas sobre la API y la SPA de Nimbus. No puede autorizar pruebas contra el proveedor cloud (A-05), contra la pasarela de pago (A-12), contra el proveedor de email (A-11) ni contra los sistemas de una clínica cliente, porque no son suyos. Un pentester que ataque la infraestructura del proveedor cloud amparándose en la autorización de Nimbus está cometiendo un acceso no autorizado, y la autorización de Marta no le protege. De ahí que la plantilla de 05-03 incluyera cláusulas expresas de activos excluidos y autorización del proveedor cloud.

Lo mismo, en versión doméstica y frecuente: el permiso de un empleado no autoriza a probar los sistemas de su empresa. Que un amigo que trabaja en una empresa te diga «prueba nuestra web, a ver si aguanta» no es una autorización válida salvo que esa persona tenga capacidad para comprometer a la organización, cosa que casi nunca ocurre.

Seis conductas que se ven a diario, defendidas con buena fe y que cruzan la línea:

Merece un párrafo el caso de la cuenta que sigue funcionando, porque es el que más veces se ve y el que más gente cree legítimo. Una persona sale de Nimbus, y tres meses después descubre que su VPN sigue activa. Entrar «para comprobar si sigue abierta» es acceso no autorizado, por mucho que el fallo sea de Nimbus. Lo correcto es avisar sin entrar: un correo a [email protected] diciendo «mi acceso sigue activo, revocadlo» es un favor; usarlo es un delito. La diferencia entre las dos cosas es un clic y varios años de consecuencias.

La ley marca el suelo. La ética profesional marca lo que se espera de alguien que sabe hacer esto, y empieza donde la ley calla.

El deber de confidencialidad sobre lo que se descubre. Quien hace seguridad ve cosas: contraseñas en un fichero, datos personales en un log, correos de un directivo, el estado real de la seguridad de un cliente. Cuatro reglas que no se negocian: lo que ves en el trabajo no se cuenta fuera, ni siquiera anonimizado en una charla, sin permiso expreso; lo que encuentras no se usa en beneficio propio, ni para conseguir un contrato ni para tener razón en una discusión; no se accede a más de lo necesario —el pentester que encuentra un IDOR extrae un registro y para, el administrador que depura no lee los mensajes—; y se destruye lo recogido al terminar —capturas, volcados, credenciales de prueba, exportaciones—, dejando constancia de esa destrucción.

El conflicto entre lo técnicamente posible y lo aceptable. Casi todo lo que se puede hacer en seguridad se puede hacer también en la dirección equivocada. Nimbus puede leer el correo de sus empleados, registrar cada pulsación de teclado, geolocalizar los portátiles y grabar las llamadas de soporte. Que sea técnicamente trivial no lo hace lícito ni aceptable: la monitorización laboral tiene límites legales estrictos, exige información previa, proporcionalidad y finalidad legítima, y en muchos casos consulta a la representación de los trabajadores. La pregunta profesional no es «¿puedo?», es «¿debo, con qué base y con qué límite?».

La responsabilidad de quien escribe herramientas. Publicar un script que automatiza una comprobación defensiva es útil; publicar uno que automatiza la explotación masiva de una vulnerabilidad recién divulgada pone un arma en manos de miles de personas antes de que nadie haya podido parchear. No hay una respuesta única —volveremos a ello en el apartado 12—, pero sí un criterio: piensa en quién lo usará el primer día y en qué defensa se hace posible que antes no lo era. Si la respuesta a la segunda pregunta es «ninguna», la publicación es difícil de justificar.

Qué hacer cuando la empresa te pide algo que no debes hacer. Es la situación más difícil de esta lección porque hay un contrato de trabajo de por medio. Tres casos reales en el mundo de Nimbus:

Cuatro principios prácticos para estas situaciones. Deja rastro: pide y da las instrucciones por escrito, porque la memoria de una conversación no protege a nadie. Escala por el camino previsto: dirección, DPD, responsable de cumplimiento, y si existe, canal interno de denuncias. Distingue el desacuerdo profesional de la ilegalidad: discrepar de una decisión de riesgo es legítimo y se acata; participar en un incumplimiento no. Y conoce tus límites: si te piden algo que puede ser ilícito, la respuesta correcta es negarte y buscar asesoramiento, porque el hecho de que te lo pida tu empresa no te exime de responsabilidad.

Nota de validación. La protección del trabajador que se niega a una instrucción, los canales internos de denuncia y la protección de personas informantes están regulados y varían según el caso. Consúltalo con un abogado laboralista antes de actuar, y documenta por escrito desde el primer momento.

Por qué el gris es un problema aunque la intención sea buena, y conviene entenderlo porque mucha gente cree estar en zona segura. Jurídicamente no existe la zona gris: el acceso fue no autorizado y el resto son atenuantes; el sombrero gris es una categoría cultural, no legal. Quien recibe el aviso no puede distinguirte de un atacante: desde el otro lado ve un acceso no autorizado y un correo de alguien que dice haber entrado, y la reacción defensiva —denunciar— es previsible y razonable desde su punto de vista. Los casos que acaban mal existen: investigadores han sido denunciados por reportar fallos hallados sin autorización, incluso sin extraer datos y avisando de inmediato, porque el resultado no depende solo de tu conducta. Y hay un desliz frecuente hacia el negro: pedir una recompensa por un fallo encontrado sin autorización puede interpretarse como extorsión.

La alternativa que casi siempre existe. Si quieres investigar la seguridad de un producto de terceros sin riesgo: busca su política de divulgación o su security.txt, y si tiene una, actúa dentro de su alcance y de su puerto seguro. Si no tiene, pide autorización antes. Y si quieres practicar explotación, hazlo donde está permitido: tu propio laboratorio, Juice Shop, DVWA, TryHackMe, HackTheBox —los mismos que 05-03 señalaba como el único sitio donde practicarla—.

La divulgación responsable —o coordinada— es el conjunto de prácticas por las que quien descubre una vulnerabilidad la comunica al responsable del producto, le da un plazo razonable para corregirla y solo después la hace pública, si procede.

Existe porque las dos alternativas puras son malas. Callar para siempre deja a los usuarios expuestos si otro encuentra el mismo fallo, y elimina el incentivo del fabricante para corregir. Publicar de inmediato entrega el fallo a los atacantes antes de que exista parche. La divulgación coordinada busca el equilibrio: quien puede arreglarlo se entera primero, y quien puede protegerse se entera cuando puede hacerlo.

El papel de los CERT como intermediarios. Cuando el contacto directo falla —no hay canal, no responden, o hay conflicto—, un equipo de respuesta a incidentes puede coordinar. En España:

• INCIBE-CERT, para ciudadanos y empresas del sector privado. Es el punto de referencia para reportar cuando no se sabe a quién dirigirse.
• CCN-CERT, para el sector público y las organizaciones bajo el ENS.
• ESPDEF-CERT, para el ámbito de la Defensa.

Su valor es doble: aportan legitimidad al reporte y capacidad de contacto con organizaciones que no publican canal. Además existen coordinadores internacionales para casos que afectan a muchos fabricantes a la vez.

Los plazos y su justificación. El estándar de facto es 90 días desde el reporte hasta la publicación, con variantes: 7 días si el fallo ya se está explotando activamente, prórroga si el fabricante muestra progreso real y la corrección es estructuralmente compleja, y publicación inmediata tras el parche si sale antes. El razonamiento: 90 días son suficientes para que una organización razonable corrija y despliegue, y son pocos como para que la presión funcione; sin plazo, muchas correcciones no llegan nunca. Y el plazo se anuncia desde el primer contacto, para que no haya sorpresas.

Qué incluir, en orden de utilidad para quien lo recibe: (1) resumen en una frase e impacto en términos de negocio —qué puede hacer un atacante y sobre qué datos—; (2) producto, versión y entorno exactos donde se reprodujo; (3) pasos de reproducción mínimos y deterministas, con la evidencia más pequeña posible; (4) alcance de lo que hiciste y —muy importante— de lo que NO hiciste; (5) mitigación sugerida, si la tienes; y (6) tu contacto, tu plazo de divulgación y tus condiciones de crédito.

Qué no hacer nunca. No exfiltrar datos «para probarlo»: un identificador ajeno visible en una respuesta demuestra el fallo; descargar 10.000 registros lo convierte en un delito y destruye tu posición. No pivotar ni escalar: encontrar una puerta no autoriza a recorrer la casa. No pedir dinero: reportar y a continuación solicitar compensación puede interpretarse como extorsión, sobre todo si va con plazo o con mención de publicar —si existe un bug bounty se reclama dentro de su proceso; si no, se reporta sin condiciones y se acepta lo que voluntariamente ofrezcan—. No publicar antes de tiempo ni adelantar capturas en redes. Y no amenazar: anunciar un plazo acordado es legítimo, «o me respondéis o lo publico mañana» no lo es.

Fíjate en que los apartados 5 y 8 son los que protegen jurídicamente al investigador: dejan por escrito y desde el primer minuto que no hubo exfiltración ni exploración adicional, y que no hay ninguna petición económica. Escribirlos cuesta dos minutos y cambia por completo cómo se lee el correo al otro lado.

Este es el lado que le toca a Nimbus, y donde 05-03 dejó la tarea pendiente: publica hoy tu security.txt, cuesta media hora. El razonamiento es simple: alguien va a encontrar un fallo en tu producto. La única pregunta es si sabrá a quién escribir y si se atreverá a hacerlo. Sin canal y sin puerto seguro, el fallo acaba en otro sitio.

Los tres errores más comunes con este fichero: dejar que Expires caduque —lo que lo invalida y transmite abandono—, poner un buzón que nadie lee, y publicarlo sin una política de divulgación detrás, que es lo que realmente da seguridad al investigador para actuar.

Las tres cláusulas que hacen útil a esta política: el puerto seguro del apartado 2, que es lo que permite a alguien investigar sin miedo; el alcance excluido del apartado 3, que protege a Nimbus de ser responsable de pruebas contra terceros y protege al investigador de creerse autorizado donde no lo está; y los plazos comprometidos del apartado 6, que convierten una declaración de intenciones en una obligación verificable. Sin las tres, el documento es decorativo.

Publicar el canal sin capacidad de responder es peor que no publicarlo: el investigador que no recibe respuesta en dos semanas publica, y con razón.

Dos decisiones que marcan la diferencia. La primera: el paso 3 puede convertirse en un incidente. Si el triaje revela que el fallo ya fue explotado por otros, deja de ser un reporte y pasa a ser una brecha, con el reloj de las 72 horas del RGPD en marcha (06-03). La segunda: el paso 9 es el que da valor duradero. Un reporte externo es una auditoría gratuita que además señala un hueco en tus propias defensas; preguntarse por qué el CI de AppSec no lo detectó convierte un fallo en una regla nueva que evita los cien siguientes.

Y el trato importa más de lo que parece. El investigador que recibe respuesta en un día, actualizaciones periódicas, crédito público y una camiseta se convierte en alguien que vuelve a mirar tu producto gratis y que habla bien de ti. El que recibe silencio y luego una carta de un abogado se convierte en un caso público que otras empresas usarán como ejemplo de lo que no hay que hacer. El coste de tratar bien un reporte es una hora de trabajo; el de tratarlo mal es la reputación (A-20).

Un bug bounty es un programa que ofrece recompensa económica por vulnerabilidades reportadas, gestionado directamente o a través de plataformas especializadas (HackerOne, Bugcrowd, Intigriti, YesWeHack).

Por qué Nimbus no debe abrir uno todavía, retomando la advertencia de 05-03: un bug bounty sin capacidad de respuesta es peor que no tenerlo. Si llegan cuarenta informes y nadie los tría en 48 horas, la comunidad lo publica y el daño reputacional supera al del fallo original. Y hay un problema de caja: las recompensas son imprevisibles —un fallo crítico puede costar miles de euros— y no encajan bien en un presupuesto de 18.000 €/año ya comprometido.

Los cuatro requisitos antes de plantearlo, en orden: (1) VDP publicada y funcionando durante al menos un año con sus plazos cumplidos; (2) capacidad demostrada de corregir una crítica en 30 días; (3) presupuesto específico y separado del de seguridad operativa, con techo anual declarado; (4) una persona con tiempo asignado para el triaje. Si falta alguno, esperar. El escalón intermedio que sí tiene sentido hoy: un programa privado y por invitación con tres o cuatro investigadores conocidos, alcance acotado y presupuesto cerrado; da la mayor parte del valor con una fracción del ruido y sirve de ensayo del proceso.

El sistema CVE (Common Vulnerabilities and Exposures), que vimos en 01-02, asigna un identificador único y público a cada vulnerabilidad para que todo el mundo hable de lo mismo: CVE-AAAA-NNNNN.

Un CNA (CVE Numbering Authority) es una organización autorizada a asignar identificadores CVE dentro de su ámbito. Los hay de tres tipos: fabricantes que asignan CVE a sus propios productos, coordinadores —como CERT/CC o INCIBE en su ámbito— que asignan a productos de terceros cuando el fabricante no es CNA o no responde, y la autoridad raíz del programa.

Cómo se solicita un CVE, en la práctica: si el fabricante es CNA, se le pide a él durante la divulgación coordinada y lo asigna él. Si no lo es, se solicita a un CNA coordinador aportando descripción, versiones afectadas, tipo de vulnerabilidad (CWE), impacto y prueba de que se intentó contactar con el fabricante. Es gratuito.

Qué papel juega el investigador y por qué merece la pena. Un CVE convierte un hallazgo en algo rastreable, citable y accionable por miles de organizaciones a la vez: entra en los feeds, lo recogen los escáneres, y de pronto el trivy de Nimbus lo detecta automáticamente en su cadena de dependencias. Ahí está el círculo completo del curso: el trabajo de un investigador desconocido acaba, semanas después, protegiendo a una PYME de Valencia sin que nadie tenga que hacer nada. Ese es el bien público que la divulgación responsable produce, y la razón de fondo para hacer las cosas bien.

Dos precisiones: no todo merece CVE —una configuración incorrecta de una instancia concreta no es una vulnerabilidad de producto—, y tener CVE no significa ser explotable en tu entorno, que es exactamente por lo que en 05-01 priorizábamos con EPSS y KEV además de CVSS.

El dilema de publicar exploits. Es probablemente el debate más antiguo y menos resuelto del sector, y tiene argumentos sólidos en ambos lados:

Criterios razonables que la práctica ha decantado, sin cerrar el debate: publicar después del parche siempre que sea posible; publicar el análisis —qué falla y por qué— antes que el arma lista para usar; graduar el detalle según lo crítico del sistema afectado, con especial cuidado en salud, industria e infraestructuras; y acompañar siempre de mitigaciones para quien todavía no puede parchear. La pregunta que ordena la decisión es la del apartado 4: qué defensa se hace posible que antes no lo era. Si la respuesta es «ninguna, pero se puede atacar más fácil», la publicación es difícil de justificar.

La ética de la IA aplicada a la seguridad. Los asistentes de IA se han vuelto herramientas cotidianas, y traen tres cuestiones nuevas que Nimbus debe resolver por política, no caso a caso:

• Filtración por prompt. Pegar en un asistente un fragmento de código con credenciales, un log con datos de clientes o un extracto de un contrato es una cesión de datos a un tercero, con todo lo que eso implica: puede ser una transferencia internacional (06-03), puede vulnerar el contrato del artículo 28 con las clínicas y puede ser un incumplimiento de confidencialidad. Que sea cómodo no lo hace lícito.
• Código generado sin revisar. Un asistente produce código plausible que puede arrastrar patrones inseguros —consultas concatenadas, autorización ausente, dependencias inventadas o abandonadas—. La responsabilidad sigue siendo de quien lo integra, y la checklist de revisión de 05-05 aplica igual, o más.
• Uso ofensivo. Los mismos modelos redactan correos de phishing impecables y sin faltas —de ahí la píldora de enero de 06-05—, lo que eleva la línea base de calidad de los ataques y refuerza la conclusión de toda esta lección: la defensa no puede depender de que la gente detecte errores de ortografía, tiene que depender del reporte y de controles técnicos.

La respuesta organizativa es una política de uso de IA, breve y clara, que forme parte de POL-04 y de la formación de 06-05: qué herramientas están aprobadas, qué nunca se pega en un asistente —secretos, datos personales, datos de clientes, código propietario según se decida—, qué revisión exige el código generado, y quién autoriza una herramienta nueva. Es una política de tres párrafos que evita un incidente entero.

• Creer que la buena intención legaliza. No existe una eximente de «lo hice para avisarles». El acceso no autorizado sigue siéndolo aunque no rompas nada y avises de inmediato.
• Aceptar una autorización inválida. Verbal, sin alcance, sin fecha, o dada por quien no puede darla. Y sobre todo: nadie puede autorizarte sobre sistemas de terceros, ni siquiera su cliente.
• Descargar datos «para probar el fallo». Convierte un hallazgo en un delito y destruye cualquier alegato de buena fe. Un identificador ajeno visible basta.
• Pedir dinero por un fallo encontrado sin autorización. Puede interpretarse como extorsión, sobre todo si va con plazo o con mención de publicar.
• Entrar «solo para comprobar» con una cuenta que sigue activa tras dejar la empresa. El derecho de acceso terminó con la relación; que el control falle no lo restituye. Avisa sin entrar.
• Publicar security.txt y no vigilar el buzón. O dejar que Expires caduque. Ambas cosas transmiten abandono y el investigador buscará otra vía.
• Abrir un bug bounty sin proceso. Cuarenta informes sin triar en 48 horas hacen más daño reputacional que el fallo original.
• Consejo: publica hoy tu security.txt y tu política de divulgación. Cuesta media jornada, es gratis y decide si el próximo fallo que alguien encuentre en tu producto llega a tu buzón o a otro sitio. Es lo que 05-03 te dejó pendiente.
• Consejo: escribe siempre en el reporte qué hiciste y qué NO hiciste. Dos frases que te protegen jurídicamente y que cambian por completo cómo se lee tu correo al otro lado.
• Consejo: ante la duda, no lo hagas y pregunta. El coste de esperar una respuesta es un día; el de equivocarte, años.

Ejercicio 1 — Cuatro situaciones, cuatro decisiones

Para cada situación, decide qué harías, justifica jurídica y éticamente, e indica qué no harías bajo ningún concepto.

1. Iván, navegando por la web de una clínica cliente, ve que la URL de un informe descargable contiene un identificador secuencial. Sospecha que hay un IDOR. La clínica es cliente de Nimbus y Marta tiene buena relación con su director.
2. Lucía descubre que su cuenta de VPN en la empresa donde trabajó hace un año sigue activa. Lo comprueba porque el gestor de contraseñas se lo autocompletó al abrir la web por error.
3. Rubén encuentra en un foro público un fichero con miles de correos y contraseñas, y ve que tres son de clientes de Nimbus.
4. Sara recibe un correo de alguien que dice haber encontrado un fallo grave en la app de Nimbus, adjunta una captura convincente y pide 3.000 € por los detalles, indicando que si no hay respuesta en 72 horas lo publicará.

Ejercicio 2 — La instrucción que no debes cumplir

Marta pide a Lucía, por chat: «Necesito que revises el correo de [empleado] de los últimos tres meses. Sospechamos que está pasando información a la competencia y no quiero avisar a nadie todavía, ni a Sara. Es urgente y confidencial.»

Analiza la petición: qué problemas plantea, en qué planos, y redacta la respuesta de Lucía —el mensaje literal que enviaría—. Indica también qué haría después y qué documentaría, y qué ocurriría si Marta insistiera.

Ejercicio 3 — Nimbus recibe su primer reporte

Llega a [email protected] un correo de una investigadora: ha encontrado que el endpoint de exportación de la API no verifica el tenant cuando se usa un token de la app móvil, y adjunta una petición y una respuesta con un identificador ajeno visible pero el contenido redactado. Dice que no ha accedido a más datos, propone 90 días y pide crédito público.

Diseña la respuesta completa de Nimbus: qué se hace en las primeras 48 horas, quién hace qué, cómo se decide si esto es además una brecha del RGPD, qué se le contesta a ella (redacta el correo) y qué se hace después de corregir.

Ejercicio 1

1. El IDOR sospechado en la web de un cliente. No lo prueba. El sistema es de la clínica, no de Nimbus, y ni Iván ni Marta pueden autorizar pruebas sobre él. Modificar el identificador para confirmar la sospecha sería un acceso no autorizado, por muy buena que sea la relación comercial y por mucho que solo pretenda avisar. Lo correcto: Iván informa a Marta de la observación, sin haberla verificado, y Marta escribe al director de la clínica describiendo lo observado —«el identificador del informe parece secuencial, lo que en ocasiones indica un problema de autorización»— y ofreciendo ayuda formal. Si la clínica quiere que Nimbus lo verifique, se hace con autorización escrita, previa y con alcance. Lo que no haría bajo ningún concepto: cambiar el número «solo una vez para estar seguro». Esa única petición es exactamente la conducta que la ley describe, y además Iván tendría que explicar por qué accedió a un informe de un paciente ajeno.

2. La cuenta de VPN que sigue activa. No entra. El derecho de acceso terminó con la relación laboral; que la empresa no lo revocara es un fallo suyo que no restituye la autorización, y «entré para comprobar si funcionaba» describe un acceso no autorizado consumado. Lo correcto: Lucía envía un correo al contacto de seguridad o a su antiguo responsable diciendo «mis credenciales de VPN siguen activas, os pido que las revoquéis», sin haberse conectado, y borra la entrada del gestor de contraseñas. Si quiere ser especialmente prudente, hace una captura del autocompletado como constancia de que no llegó a autenticarse. Nunca: conectarse «para ver hasta dónde llego» ni compartir el hallazgo en redes. Nota adicional: para la empresa receptora, este aviso es una no conformidad de su proceso de bajas y debería abrir una acción correctiva (06-04).

3. El volcado de credenciales con clientes de Nimbus. Aquí hay que separar dos cosas. Sobre el fichero: no se descarga ni se conserva, y desde luego no se prueban las credenciales contra ningún servicio —eso sería credential stuffing, es decir, acceso no autorizado, aunque el objetivo sea comprobar el riesgo—. Sobre los clientes: Nimbus sí puede y debe actuar sobre lo suyo. Lo correcto: (a) forzar el restablecimiento de contraseña de las cuentas afectadas y revocar sus sesiones activas, sin necesidad de probar nada; (b) revisar la tabla de auditoría (C-07) y las detecciones D-01/D-02 buscando accesos anómalos previos a esas cuentas; (c) avisar a los clientes con un mensaje claro y sin alarmismo, indicando que sus credenciales aparecen en un volcado público de terceros y que deben cambiarlas también donde las hayan reutilizado; (d) valorar con el DPD si procede alguna actuación bajo el RGPD —normalmente no hay brecha en Nimbus si las credenciales proceden de otro servicio, pero si hubo accesos exitosos sí la habría—; y (e) usarlo como argumento para acelerar el MFA de clientes. Y la medida estructural: suscribirse a un servicio legítimo de vigilancia de credenciales filtradas, que hace esto de forma continua y sin manipular volcados.

4. La petición de 3.000 €. El patrón —pago antes de dar los detalles, plazo de 72 horas y amenaza implícita de publicar— no es divulgación responsable, y puede ser constitutivo de un delito de extorsión. Es muy distinto de un investigador que reporta y luego acepta una recompensa voluntaria. Lo correcto: (a) no pagar y no negociar el pago; (b) responder de forma profesional y sin hostilidad, porque puede tratarse de alguien mal aconsejado y no de un extorsionador: agradecer el aviso, remitir a la política de divulgación de Nimbus, explicar que no hay recompensa económica pero sí crédito público, y pedir los detalles conforme a esa política; (c) conservar el correo íntegro con sus cabeceras como evidencia; (d) consultar con asesoría jurídica antes de la siguiente respuesta; (e) en paralelo, tomarse en serio el fondo: la captura es convincente, así que Lucía e Iván buscan el fallo por su cuenta y revisan los registros por si ya hubo explotación —lo que lo convertiría en un incidente y activaría el reloj del RGPD—. Lo que no haría: pagar, amenazar de vuelta, o ignorarlo.

Ejercicio 2

Problemas que plantea, en tres planos:

• Jurídico y de protección de datos. El acceso al correo de una persona trabajadora afecta a derechos fundamentales y está sujeto a límites estrictos: necesidad, proporcionalidad, mínima intrusión y, con carácter general, información previa sobre las facultades de control del empresario. Un acceso indiscriminado a tres meses de correspondencia difícilmente supera un juicio de proporcionalidad, y la prueba obtenida así puede además resultar inválida en un procedimiento posterior, con lo que la medida no solo es arriesgada: puede ser inútil para lo que Marta pretende.
• Laboral. Existen implicaciones de convenio y, en su caso, de información a la representación de los trabajadores. Una actuación mal hecha puede convertir un caso de fuga de información en un caso de vulneración de derechos del trabajador, invirtiendo por completo las posiciones.
• De control interno. Se pide saltarse el proceso: sin registro, sin aprobación documentada, sin el DPD y excluyendo expresamente a Sara (RRHH). Es exactamente el patrón que 06-04 identifica como el camino alternativo por el que se rompen los controles. Y compromete personalmente a Lucía, que quedaría como única ejecutora de un acceso sin cobertura.

Respuesta de Lucía:

Qué hace después y qué documenta. No ejecuta el acceso al correo. Lanza la revisión de actividad, que sí tiene base y es proporcionada, y documenta: la petición recibida, su respuesta, la fecha, el alcance de lo que sí ha revisado y su resultado. Si la consulta al DPD y a asesoría autoriza un acceso acotado —por ejemplo, a metadatos o a correos con destinatarios externos concretos en un periodo delimitado—, lo ejecuta con ese alcance exacto, con doble presencia si es posible y dejando registro.

Si Marta insiste sin la cobertura: Lucía reitera su posición por escrito, pide la instrucción firmada asumiendo la responsabilidad, y si aun así se le exige ejecutar, escala al DPD y busca asesoramiento propio. La regla de fondo del apartado 4: el hecho de que te lo pida tu empresa no te exime de responsabilidad. Y una observación que conviene hacer explícita: Marta no está actuando de mala fe, está actuando con prisa ante un problema real. Por eso la respuesta correcta no es una negativa seca, sino ofrecer un camino que resuelva su problema legítimo dentro del marco. Esa es, exactamente, la diferencia entre el «departamento del no» de 06-01 y un profesional útil.

Ejercicio 3

Primeras 48 horas.

• Hora 0-2 — Acuse de recibo (Marta). Respuesta personal, no automática, agradeciendo, dando un nombre y un contacto directo, y confirmando el plazo de 90 días que ella propone. Cumple el compromiso de 2 días laborables de la política y fija el tono de toda la relación.
• Hora 2-8 — Triaje (Iván y Lucía). Reproducir en preproducción. El fallo descrito es grave: un token de la app móvil que no pasa por la comprobación de tenant en el endpoint de exportación significa que cualquier cliente puede exportar datos de otros, y en tenants de clínicas eso son datos que revelan salud. Se clasifica crítica por CVSS, exposición (Internet, autenticado) y sensibilidad de los datos.
• Hora 8-24 — La pregunta decisiva: ¿ha sido explotado? Se consulta la tabla de auditoría append-only (C-07) y los registros de acceso al bucket A-02 buscando exportaciones desde tokens móviles con tenant no coincidente, en toda la ventana de retención. Aquí se decide si esto es un reporte o una brecha.
• Hora 24-48 — Contención y corrección. Si el impacto lo justifica, se desactiva temporalmente la exportación desde la app móvil mientras se corrige. La corrección es estructural, no un parche puntual: el endpoint pasa por la dependencia tenant_actual/exige() como todos los demás, se añade el filtro WHERE tenant_id, y se escribe un test de regresión que reproduce exactamente el caso del reporte.

Cómo se decide si además es una brecha del RGPD. Con el criterio de 06-03: si la auditoría muestra accesos reales a datos de otros tenants, hay violación de la seguridad de datos personales, Nimbus es encargado y debe notificar a cada clínica afectada en 24 horas conforme al contrato, para que ellas notifiquen a la AEPD dentro de sus 72 horas. Si la auditoría no muestra ningún acceso cruzado en toda la ventana de retención, es una vulnerabilidad no explotada: no hay brecha, pero se documenta el análisis y su conclusión, porque es la evidencia que respalda la decisión de no notificar. Y si la retención de logs no cubre todo el periodo en que el fallo existió, hay que decirlo con honestidad: no poder descartar el acceso no es lo mismo que descartarlo, y la decisión debe tomarse con el DPD. Ese matiz es el que suele determinar el resultado real de estos casos.

Correo a la investigadora (día 1):

Después de corregir. Cinco cosas, y las cinco importan: (1) invitar a la investigadora a verificar —es el retest de 05-03, y ahora gratis—; (2) publicar el aviso y el crédito acordados, y actualizar la página de agradecimientos; (3) preguntarse por qué no lo detectamos nosotros, que es el paso 9 del circuito: el CI tenía pruebas de autorización, pero solo para tokens web, así que se extienden a los tokens móviles y se escribe una regla semgrep que detecte cualquier consulta a datos de cliente sin filtro de tenant; (4) actualizar la matriz de trazabilidad de 06-04 con esta evidencia y revisar si el riesgo R-04 del registro de 04-01 cambia; y (5) llevarlo como caso a la formación de desarrollo de 06-05 —el mejor ejemplo posible, porque es código propio, es reciente y lo encontró alguien de fuera—. Un reporte externo bien gestionado no cierra un fallo: cierra una clase entera de fallos.

Has cerrado la parte lectiva del curso con lo que 05-03 dejó pendiente y lo que separa a un técnico competente de un profesional. Conoces la línea legal: el acceso ilícito del artículo 197 bis, la interceptación, la facilitación de herramientas del 197 ter, los daños del 264 y la obstaculización del 264 bis, con las cinco precisiones que evitan malentendidos —el acceso ilícito no exige daño ni habilidad, mantenerse cuenta, existen tipos agravados y la responsabilidad penal no es la única— y con la constatación de que no existe una eximente de buena intención. Sabes qué hace válida a una autorización: que la dé quien puede, con alcance explícito, ventana temporal, por escrito y antes; y sabes el caso que casi todo el mundo se salta, que nadie puede autorizarte sobre sistemas de terceros —ni Marta sobre el proveedor cloud, ni un empleado sobre su empresa—. Y reconoces las seis conductas que la gente cree legales y no lo son, con la más frecuente y peor entendida: entrar con la cuenta que sigue activa tras dejar la empresa, cuando lo correcto es avisar sin entrar.

Manejas la ética profesional más allá de la ley: el deber de confidencialidad con sus cuatro reglas, la distinción entre lo técnicamente posible y lo aceptable —la pregunta no es «¿puedo?», es «¿debo, con qué base y con qué límite?»—, la responsabilidad de quien escribe herramientas, y el caso más difícil de todos: qué hacer cuando la empresa te pide monitorizar sin base, ocultar una brecha o retrasar una notificación. Con los cuatro principios que lo ordenan: deja rastro, escala por el camino previsto, distingue el desacuerdo profesional de la ilegalidad, y recuerda que el hecho de que te lo pida tu empresa no te exime de responsabilidad. Y sabes por qué el sombrero gris es un problema jurídico aunque la intención sea buena: no existe como categoría legal, quien recibe el aviso no puede distinguirte de un atacante, y pedir una recompensa por un fallo hallado sin autorización puede leerse como extorsión.

Dominas la divulgación responsable: por qué existe, sus tres modalidades con sus consecuencias, el papel de INCIBE-CERT y CCN-CERT como intermediarios, y los plazos habituales de 90 días con su justificación. Sabes reportar bien —resumen, impacto, reproducción mínima, y sobre todo qué hiciste y qué no, más la ausencia de petición económica, que son los dos apartados que te protegen— y sabes lo que no se hace nunca: exfiltrar, pivotar, pedir dinero, publicar antes o amenazar. Y sabes recibir bien, que es el lado de Nimbus: el security.txt completo con su Expires que hay que renovar, y una política de divulgación cuyas tres cláusulas útiles son el puerto seguro, el alcance excluido y los plazos comprometidos. Con el circuito interno de nueve pasos, sus dos decisiones críticas —que el triaje puede convertirse en un incidente con el reloj de las 72 horas, y que el paso de aprendizaje es el que da valor duradero— y la aritmética que lo justifica: tratar bien un reporte cuesta una hora; tratarlo mal cuesta la reputación.

Sabes cuándo tiene sentido un bug bounty y por qué Nimbus no debe abrirlo todavía, con los cuatro requisitos previos y el escalón intermedio del programa privado por invitación. Conoces el sistema CVE y qué es un CNA, cómo se solicita un identificador y por qué merece la pena: el trabajo de un investigador desconocido acaba, semanas después, protegiendo a una PYME de Valencia porque su trivy lo detecta solo. Y cierras con los dos debates abiertos: el dilema de la publicación de exploits, con la pregunta que lo ordena —qué defensa se hace posible que antes no lo era—, y la ética de la IA en seguridad, con la filtración por prompt como cesión de datos a un tercero, el código generado que sigue siendo responsabilidad de quien lo integra, y el phishing sin faltas que confirma la tesis de 06-05: la defensa no puede depender de detectar errores de ortografía, tiene que depender del reporte.

Con esto se cierra el Módulo 6 y con él la parte lectiva del curso. Mira atrás un momento y verás el recorrido completo: empezaste con la tríada CIA y el vocabulario del riesgo (módulo 1), entendiste el panorama de amenazas y cómo se defiende una organización (módulo 2), aprendiste a proteger la información con criptografía que se usa de verdad (módulo 3), a decidir con un registro de riesgos, políticas, controles y un plan de respuesta (módulo 4), a ejecutar con herramientas, detección, pentest, redes, aplicaciones, endpoint y nube (módulo 5), y por último a sostener y demostrar lo hecho con hábitos, normativas, RGPD, evidencia, personas y ética (módulo 6). Y todo ello sobre una empresa concreta: 38 personas, 18.000 € al año, una sola administradora de sistemas, un incidente que costó 20 días de ceguera y 1,2 TB, y un plan que cabe en el presupuesto real.

Ahora te toca a ti. En el Módulo 7: Proyecto Final dejas de leer sobre Nimbus y aplicas todo esto a un caso propio: inventariar y clasificar los activos de una organización, identificar y priorizar sus riesgos, diseñar un catálogo de controles ajustado a un presupuesto real, definir su plan de respuesta y su estrategia de recuperación, elegir el marco normativo que le aplica, montar su matriz de trazabilidad y su plan de concienciación, y defender las decisiones con el mismo criterio con el que Marta ha tenido que defender las suyas en cada lección. En 07-01 empieza el enunciado. Lo que se te va a pedir no es que sepas: es que decidas, priorices y lo justifiques, que es exactamente lo que se espera de un profesional de la seguridad el primer día de trabajo.