Hackeo Ministerio de Ciencia 2026: Lecciones IDOR para Administraciones Públicas

El 2-3 de febrero de 2026, un hacker que se identifica como “ScienceLeaks” afirmó haber comprometido la base de datos del Ministerio de Ciencia, Innovación y Universidades mediante una vulnerabilidad IDOR (Insecure Direct Object Reference). Según el atacante, obtuvo acceso completo a datos de estudiantes becarios, investigadores postdoctorales, solicitantes de ayudas I+D+i, CVs completos y proyectos de investigación sensibles.

Este es el TERCER caso IDOR en administraciones públicas españolas en menos de 30 días (Hacienda el 2 de febrero, Ministerio Ciencia 2-3 de febrero). Como perito informático forense, este patrón revela un problema sistémico de seguridad en el sector público que requiere acción urgente.

En este artículo analizo la cronología del incidente, por qué las administraciones son especialmente vulnerables a IDOR, el marco legal que las protege (y que incumplen), y las lecciones que TODAS las administraciones públicas deben aprender de esta oleada de ataques.

TL;DR - Resumen Ejecutivo

En 60 segundos:

Qué: Hacker afirma acceso completo a base datos Ministerio Ciencia (estudiantes, investigadores, proyectos I+D)
Método: Vulnerabilidad IDOR (misma que Hacienda) - tercera administración atacada en 30 días
Datos expuestos: DNI, emails, CVs, proyectos investigación, datos académicos completos
Problema sistémico: Sistemas legacy de 10-15 años, falta auditorías ENS, desarrollo externalizado sin control
Marco legal: Esquema Nacional Seguridad (ENS) obliga auditorías cada 2 años - 60% incumple
Lecciones: Auditoría urgente TODOS los sistemas públicos, formación desarrolladores OWASP, monitorización 24/7

Auditoría ENS administraciones públicas →

El Supuesto Hackeo al Ministerio de Ciencia: Lo Que Sabemos

2-3 de Febrero 2026: La Alerta

Según reportes de Hipertextual y Hackmanac, el hacker “ScienceLeaks” afirmó en foros clandestinos haber comprometido los sistemas del Ministerio de Ciencia, Innovación y Universidades mediante explotación de vulnerabilidad IDOR.

Aspecto	Detalle
Fecha alerta	2-3 de febrero 2026
Actor	”ScienceLeaks” (identidad desconocida)
Método	Vulnerabilidad IDOR (mismo que Hacienda)
Datos comprometidos	Estudiantes becarios, investigadores, solicitantes ayudas I+D
PII expuesta	DNI, emails, teléfonos, direcciones, CVs, proyectos investigación
Estado oficial	Ministerio investiga, sin confirmación ni desmentido completo
Investigación	CCN-CERT + INCIBE coordinando análisis forense

Sistemas Potencialmente Afectados

Basándome en la descripción del atacante y los sistemas públicos del Ministerio de Ciencia, los portales comprometidos podrían incluir:

Portal Becas Predoctorales y Postdoctorales:

Sistema de solicitud FPI (Formación Personal Investigador)
Becas predoctorales convocatoria anual
Programas movilidad internacional investigadores
Datos: DNI, expediente académico completo, cartas recomendación, proyectos tesis

Sistema Ayudas I+D+i:

Convocatorias proyectos investigación competitivos
Planes estatales I+D+i
Ayudas infraestructuras científicas
Datos: Presupuestos proyectos, memorias técnicas, CVs equipos investigación

Base Datos Investigadores Acreditados:

ANECA (Agencia Nacional Evaluación Calidad y Acreditación)
Acreditaciones profesorado universitario
Sexenios investigación
Datos: CVs completos, publicaciones, líneas investigación, evaluaciones

Convocatorias Proyectos Científicos:

Proyectos Excelencia, Retos, Generación Conocimiento
Colaboraciones internacionales (ERC, Horizonte Europa)
Datos sensibles: Proyectos defensa, biomedicina con datos clínicos, propiedad industrial

Riesgo Espionaje Industrial

Proyectos de investigación estratégicos expuestos representan un riesgo de espionaje industrial y científico. Competidores internacionales o actores estatales hostiles podrían acceder a:

Metodologías de investigación innovadoras
Resultados preliminares de experimentos
Colaboraciones científicas sensibles
Presupuestos y recursos asignados a áreas estratégicas

Cronología del Incidente

2 de Febrero 2026: el hacker “ScienceLeaks” publica en un foro clandestino afirmando acceso completo a la base de datos del Ministerio de Ciencia mediante IDOR.
3 de Febrero: el grupo Hackmanac verifica la credibilidad de la alerta. Medios tech reportan el supuesto hackeo. CCN-CERT inicia una investigación preliminar.
4-5 de Febrero: el Ministerio de Ciencia NO emite comunicado oficial ni desmentido (contrasta con la respuesta rápida de Hacienda). El silencio institucional genera incertidumbre.
Estado actual (6 Feb 2026): investigación forense en curso coordinada por CCN-CERT e INCIBE. Sin confirmación oficial de brecha ni desmentido categórico.

Vulnerabilidad IDOR (Otra Vez): Patrón Preocupante

Tercer Caso IDOR en Administraciones en 30 Días

Este es el tercer caso IDOR en administraciones públicas españolas en menos de 1 mes:

Administración	Fecha	Datos Afectados	Estado Oficial
Hacienda (AEAT)	2-3 Feb 2026	47.3M contribuyentes (DNI, IBAN, fiscal)	Investigación en curso
Ministerio Ciencia	2-3 Feb 2026	Estudiantes, investigadores, proyectos I+D	Sin confirmación ni desmentido
Hacienda (anterior alerta)	5 Feb 2026	Desmentido oficial tras investigación	Descartado

Patrón observable:

✅ Mismo vector de ataque: IDOR (enumeración secuencial IDs sin autenticación)
✅ Mismo tipo de víctima: Administraciones públicas con sistemas legacy
✅ Misma ventana temporal: Febrero 2026 (¿campaña coordinada?)
✅ Mismo perfil atacante: Hackers “activistas” con motivación exponer vulnerabilidades

¿Por Qué las Administraciones Son Especialmente Vulnerables a IDOR?

Como perito que ha auditado sistemas de administraciones públicas, identifico 4 causas sistémicas de esta vulnerabilidad recurrente:

1. Sistemas Legacy de 10-15 Años:

Muchos portales públicos fueron desarrollados antes del RGPD (2018) y del Esquema Nacional Seguridad actualizado (2010)
Tecnologías obsoletas: PHP 5.x, Java 6-7, frameworks sin soporte
Arquitecturas monolíticas sin separación de capas (lógica negocio + acceso datos mezclados)
Ejemplo real: Portal becas predoctorales funcionando desde 2009 sin revisión de seguridad

2. Falta de Presupuesto para Modernización IT:

Presupuesto TI administraciones: 1-3% del total (sector privado: 5-8%)
Inversión se prioriza en funcionalidades visibles (tramitación electrónica) sobre seguridad
Mantenimiento correctivo (apagar fuegos) vs mantenimiento evolutivo (refactorización segura)
Dato: Solo 40% administraciones locales tienen presupuesto específico ciberseguridad

3. Desarrollo Externalizado Sin Auditorías de Seguridad:

80% desarrollo software público externalizado a empresas integradoras
Contratos sin cláusulas de auditoría de seguridad obligatoria
Desarrolladores externos sin formación OWASP Top 10
Patrón: Se entrega software funcionalmente completo pero inseguro

4. Cultura “Funcionalidad Primero, Seguridad Después”:

Presión por lanzar portales antes de plazos políticos (elecciones, convocatorias anuales)
Auditorías de seguridad vistas como “burocracia que ralentiza”
Paradigma: “Si funciona, no lo toques” (aunque sea inseguro)
Consecuencia: Vulnerabilidades IDOR triviales existen durante años sin detectar

Comparativa Sector Público vs Privado

Tiempo medio detección vulnerabilidad IDOR:

Sector privado tech: 14-30 días (bug bounties activos, auditorías continuas)
Administraciones públicas: 2-5 años (según auditorías ENS irregulares)

Coste remediación:

Sector privado: €5K-€15K por sistema (prioridad alta, recursos asignados)
Administraciones: €50K-€200K por sistema (procedimiento contratación pública, plazos largos)

Impacto en el Sector Académico y Científico

Estudiantes de Doctorado: Datos Personales + Proyectos Investigación

Datos típicamente almacenados en solicitudes de becas predoctorales:

Datos personales: DNI, dirección, teléfono, email, IBAN (para cobro beca)
Datos académicos: Expediente completo (notas por asignatura), cartas recomendación profesores
Proyectos investigación: Memoria tesis (30-50 páginas), metodología, objetivos, estado del arte
Datos sensibles: En algunos casos, declaración responsable sobre situaciones discapacidad/vulnerabilidad

Riesgo de exposición:

❌ Suplantación identidad académica (solicitar becas con datos de víctima)
❌ Robo propiedad intelectual (proyectos tesis innovadores)
❌ Phishing dirigido (emails personalizados a becarios)

Investigadores Seniors: CVs Completos y Líneas Investigación

Información estratégica expuesta:

CVs académicos completos: Publicaciones, patentes, proyectos liderados, colaboraciones internacionales
Líneas de investigación activas: Áreas estratégicas, metodologías innovadoras
Presupuestos asignados: Recursos económicos por proyecto (información competitiva)
Colaboraciones: Universidades, centros investigación, empresas privadas

Riesgo espionaje industrial:

Competidores internacionales identifican proyectos prometedores para replicar
Empresas privadas detectan innovaciones antes de protección patentes
Actores estatales hostiles mapean capacidades científicas nacionales en áreas sensibles (defensa, energía, salud)

Caso Especial: Proyectos Investigación Sensibles

Áreas de investigación con riesgo CRÍTICO si expuestas:

Área Investigación	Riesgo	Motivación Atacante
Proyectos defensa	CRÍTICO	Espionaje militar (capacidades I+D defensa nacional)
Investigación biomédica con datos clínicos	ALTO	Datos salud protegidos por RGPD + Ley 41/2002
Colaboraciones UE sensibles (ERC, Horizonte Europa)	ALTO	Espionaje científico-industrial (innovaciones tecnológicas)
Ciberseguridad y criptografía	ALTO	Contramedidas adversarios (saber qué capacidades detectamos)
Energías renovables estratégicas	MEDIO	Competitividad industrial (patentes energía)

Escenario ilustrativo: un proyecto de defensa comprometido

Un ejemplo de por qué estos datos importan: el portal de proyectos de investigación de una universidad sufre un acceso no autorizado y, entre lo expuesto, aparece un proyecto de I+D en defensa —metodología, algoritmos, prototipo—. Un caso así no expone datos personales corrientes, sino capacidades tecnológicas estratégicas, y quien las busca rara vez es un ciberdelincuente común. Es un escenario construido sobre una tipología real de la práctica pericial, no el relato de un expediente concreto.

Marco Legal: Obligaciones de las Administraciones Públicas

RGPD Aplica Igual a Sector Público

Mito común: “Las administraciones públicas tienen excepciones RGPD”

Realidad: el RGPD se aplica igual a las administraciones, y quien lo prueba es el artículo 2, que fija el ámbito de aplicación: su apartado 1 no distingue por la naturaleza de quien trata los datos, y su apartado 2 enumera las exclusiones tasadas —actividades fuera del Derecho de la Unión, política exterior y de seguridad común, uso estrictamente doméstico y los fines policiales y penales que van por la Directiva (UE) 2016/680—. Una administración ordinaria no está en esa lista. A ello se suma el artículo 4.7, que al definir «responsable del tratamiento» incluye expresamente a la autoridad pública. Las administraciones están sujetas a:

✅ Art. 32 RGPD: Obligación implementar medidas técnicas y organizativas apropiadas
✅ Art. 33 RGPD: Notificación brechas a AEPD en 72h
✅ Art. 34 RGPD: Notificación a interesados si riesgo alto
✅ Art. 82 RGPD: Responsabilidad por daños y perjuicios

Cómo responde la AEPD frente a una administración pública: a diferencia de una empresa privada, una administración no recibe la multa económica del art. 83 RGPD. El art. 77 de la LOPDGDD reserva para ella el apercibimiento, la orden de adoptar medidas correctoras y la posible incoación de un procedimiento disciplinario contra el personal responsable. La consecuencia económica llega por otras dos vías: la responsabilidad patrimonial de la Administración frente a los ciudadanos perjudicados (art. 106 CE) y la responsabilidad penal de los funcionarios (art. 197 CP).

Esquema Nacional de Seguridad (ENS) - RD 3/2010

El ENS es de obligado cumplimiento para TODAS las administraciones públicas españolas (Art. 3 RD 3/2010):

Niveles de Seguridad ENS:

Nivel	Sistemas Aplicables	Medidas Requeridas
BAJO	Información NO clasificada, sin datos personales	Las medidas del anexo II del RD 311/2022 en su nivel básico
MEDIO	Información con datos personales (DNI, email, etc.)	Las medidas del anexo II del RD 311/2022, con los refuerzos que ese anexo marca para la categoría media
ALTO	Información clasificada, datos especialmente protegidos	Las medidas del anexo II con los refuerzos adicionales que marca para la categoría alta

Portal de becas Ministerio Ciencia: Como mínimo ENS MEDIO (almacena DNI, IBAN, datos académicos).

Controles ENS MEDIO más críticos para prevenir IDOR:

Control ENS	Descripción	¿Previene IDOR?
op.acc.5	Mecanismo de autenticación	✅ SÍ (autenticar ANTES de acceder datos)
op.acc.6	Mecanismo de autorización	✅ SÍ (verificar permisos por registro)
op.exp.6	Protección API	✅ SÍ (WAF, rate limiting)
op.exp.8	Registros de actividad	⚠️ Detecta (no previene, pero permite auditoría)
op.cont.4	Protección servicios expuestos	✅ SÍ (firewall aplicación)

Auditorías ENS obligatorias cada 2 años (Art. 34 ENS). Según datos CCN-CERT:

❌ Solo 60% de administraciones cumplen auditorías bianuales
❌ Solo 42% implementan todas las medidas requeridas por su nivel
❌ Consecuencias incumplimiento: Prácticamente ninguna (impunidad de facto)

Responsabilidad Penal Funcionarios (Art. 197 CP)

Funcionarios públicos que gestionen sistemas con datos personales tienen responsabilidad penal si incumplen deber de confidencialidad:

Código Penal Art. 197.2:

“El funcionario público que, por razón de su cargo, se apodere de datos reservados de carácter personal o familiar de otro, los revele o ceda a tercero, será castigado con penas de prisión de 3 a 5 años…”

Interpretación en caso de brecha por negligencia:

Si el funcionario responsable IT NO implementó medidas ENS obligatorias
Y como consecuencia se produjo brecha de datos
Podría considerarse revelación negligente (Art. 197.3 - prisión 1-3 años)

Precedente: Caso Universidad Pública 2021 - CIO investigado penalmente tras brecha datos 50K estudiantes por no implementar auditorías ENS obligatorias (archivo provisional, pero investigación abierta).

Análisis Forense en Administraciones Públicas: Particularidades

Cadena de Custodia en Entorno Público (Más Rigurosa)

Cuando realizo análisis forense post-brecha en administración pública, la cadena de custodia es aún más estricta que en sector privado:

Particularidades legales:

📋 Documentación exhaustiva de CADA acceso a evidencia digital (registros firmados)
👥 Testigos: Mínimo 2 funcionarios presentes durante adquisición forense
🔐 Precintado físico de equipos con firma Secretaría General (no solo perito)
⚖️ Informe pericial puede derivar en responsabilidad penal funcionarios (no solo civil)

Ejemplo proceso:

Notificación formal a responsable sistema (Secretaría General Técnica)
Presencia obligatoria: Responsable IT + Responsable Seguridad + Secretario Judicial (si procede)
Adquisición forense con herramientas certificadas (FTK Imager, EnCase)
Triple copia hash (MD5 + SHA-256 + SHA-512) con testigos firmantes
Precinto físico disco original + copias forenses en caja fuerte administración
Cadena custodia documentada para cada acceso posterior

Coordinación con CNI/CCN-CERT

En brechas de administraciones públicas con sistemas clasificados o infraestructuras críticas, la investigación forense requiere coordinación con:

CNI (Centro Nacional Inteligencia): Si sistemas clasificados comprometidos
CCN-CERT (Centro Criptológico Nacional): Coordinación técnica, capacidades forenses avanzadas
INCIBE: Asistencia técnica, recursos forenses especializados
Policía Nacional (Unidad Central de Ciberdelincuencia): Investigación penal

Consecuencia práctica: Plazos de investigación forense más largos (3-6 meses vs 2-4 semanas sector privado) por coordinación multi-agencia.

Lecciones para Todas las Administraciones Públicas

5 Lecciones Críticas

Lección 1: Auditar TODOS los Endpoints API

❌ Error común: Solo auditar portales web visibles, ignorar APIs backend
✅ Acción: Inventario completo TODAS las APIs (internas y públicas) con análisis de control de acceso
🛠️ Herramienta: Burp Suite Pro, OWASP ZAP, Postman para testing autorización

Lección 2: Implementar WAF con Reglas Anti-Enumeración

❌ Error común: Firewall de red (capa 3-4) pero no firewall de aplicación (capa 7)
✅ Acción: WAF con reglas personalizadas detectando enumeración secuencial (e.g., 100 requests a /api/user?id=X incrementando X)
🛠️ Herramienta: ModSecurity, Cloudflare WAF, AWS WAF

Lección 3: Monitorización 24/7 (No Solo Horario Laboral)

❌ Error común: SOC funciona 8h-15h lunes-viernes, ataques ocurren fines de semana
✅ Acción: SIEM con alertas automáticas 24/7 + guardia técnica rotativa
🛠️ Herramienta: Splunk, ELK Stack, Wazuh (open source)

Lección 4: Formar a Desarrolladores en OWASP Top 10

❌ Error común: Desarrolladores sin formación específica en seguridad aplicaciones
✅ Acción: Formación obligatoria OWASP Top 10 + Secure Coding para TODOS los desarrolladores (internos y externos)
📚 Recurso: OWASP Top 10 2021, cursos certificación PortSwigger Web Security Academy

Lección 5: Bug Bounty Programs (Recompensas Reportar Vulnerabilidades)

❌ Error común: Criminalizar investigadores seguridad que reportan vulnerabilidades de buena fe
✅ Acción: Programa bug bounty público: Recompensas €500-€5.000 por vulnerabilidades críticas reportadas responsablemente
📋 Modelo: HackerOne Government, Bugcrowd Public Sector

Checklist ENS para Prevenir IDOR

Para administraciones públicas que almacenan datos personales (ENS nivel MEDIO obligatorio):

Inventario completo de sistemas con acceso a datos personales: listado de TODOS los portales web, APIs y bases de datos con DNI/IBAN/datos académicos.
Análisis de riesgos según ENS (Anexo I): evaluar impacto, probabilidad y nivel de seguridad requerido para cada sistema.
Implementación de las medidas del ENS para categoría media: priorizar op.acc.5 (autenticación), op.acc.6 (autorización) y op.exp.6 (protección de API).
Auditoría externa cada 2 años: contratar un auditor externo acreditado ENS (certificado CCN-CERT).
Simulacros de respuesta a incidentes: ejercicios anuales de brecha simulada con participación de CCN-CERT.

Perspectiva del Perito: Recomendaciones para el Sector Público

Urgencia: Auditoría Completa de Todos los Sistemas Públicos

Recomendación inmediata: El Ministerio de Transformación Digital y Función Pública debería ordenar auditoría extraordinaria de seguridad de TODOS los sistemas públicos con datos personales (no esperar ciclo bianual ENS).

Propuesta de acción 90 días:

Semana	Acción	Responsable
1-2	Inventario completo sistemas datos personales (estatal, autonómico, local)	CCN-CERT + Ministerio TDFP
3-4	Priorización sistemas críticos (alto volumen datos, alto impacto)	Comité Seguridad Nacional
5-8	Auditoría express sistemas críticos (pentesting IDOR focalizado)	Auditores externos acreditados
9-12	Remediación vulnerabilidades CRÍTICAS detectadas	Administraciones afectadas

Coste estimado: €50K-€200K por administración según tamaño —frente a la responsabilidad patrimonial por los daños a los ciudadanos y la penal de los funcionarios que puede acarrear una brecha no contenida.

Metodología: OWASP Testing Guide + ENS

Framework auditoría recomendado:

OWASP Testing Guide v4.2 (metodología general pentesting apps web)
Controles ENS nivel MEDIO (marco legal obligatorio España)
ISO 27001 (gestión de seguridad información)
NIST Cybersecurity Framework (mejores prácticas internacionales)

Foco específico IDOR:

Testing de control de acceso: ¿Validación autorización en CADA endpoint?
Enumeración secuencial IDs: ¿Protección contra fuerza bruta?
Referencias directas a objetos: ¿Se usan IDs predecibles o UUIDs aleatorios?
Rate limiting: ¿Límite de requests/segundo por IP?

Timeline y Priorización

Prioridad CRÍTICA (30 días):

Sistemas con más de 100K registros de ciudadanos (IBAN, DNI, datos salud)
Portales becas, ayudas sociales, sanitarios
Infraestructuras críticas (energía, transporte, agua)

Prioridad ALTA (60 días):

Sistemas con más de 10K registros
Portales educativos, laborales, consumo

Prioridad MEDIA (90 días):

Sistemas con menos de 10K registros
Portales informativos sin datos personales

Preguntas Frecuentes (FAQs)

¿Cómo sé si mis datos del Ministerio de Ciencia fueron robados?

Estado actual (6 Feb 2026): El Ministerio de Ciencia NO ha emitido comunicado oficial confirmando ni desmintiendo categóricamente la brecha. Por tanto:

⚠️ Si solicitaste becas predoctorales/postdoctorales en 2020-2026, asume riesgo MEDIO de exposición
⚠️ Si presentaste proyectos investigación I+D+i en 2020-2026, asume riesgo MEDIO-ALTO
✅ Monitoriza email por posibles notificaciones oficiales Ministerio
✅ Activa alertas fraude si tu IBAN estaba en solicitudes (bancos permiten alertas gratis)

Cómo verificar:

Contacta con Ministerio de Ciencia (Subdirección General de Tecnologías de la Información)
Solicita confirmación formal si tus datos están en sistemas afectados
Exige respuesta escrita según RGPD Art. 15 (derecho de acceso)

¿Debo preocuparme si soy investigador o becario?

SÍ, deberías tomar precauciones, independientemente de confirmación oficial:

Riesgos específicos investigadores/becarios:

📧 Phishing dirigido: Emails personalizados con datos reales tuyos (nombre, proyecto, director tesis) pidiendo “actualizar datos bancarios”
🎓 Suplantación identidad académica: Alguien solicitando becas con tus datos (nombre, DNI, expediente)
💡 Robo propiedad intelectual: Proyectos tesis innovadores copiados antes de publicación
🏦 Fraudes IBAN: Si proporcionaste IBAN para cobro beca, riesgo domiciliaciones fraudulentas

Acciones protección inmediatas:

Cambia contraseñas portales Ministerio Ciencia, universidades, ANECA
Activa MFA en TODOS los servicios académicos que lo permitan
Monitoriza IBAN semanalmente si lo facilitaste en solicitudes
Vigilancia extrema emails solicitando datos o cambios bancarios

¿Pueden robar mi proyecto de investigación?

SÍ, es técnicamente posible, y representa el riesgo MÁS GRAVE para investigadores:

Qué expones en solicitudes becas:

Memoria completa del proyecto (30-50 páginas)
Metodología detallada de la investigación
Estado del arte (qué se sabe ya, qué vas a innovar)
Objetivos y cronograma
Resultados preliminares (si es beca postdoctoral)

Riesgo de robo:

Competidores pueden replicar tu metodología y publicar antes que tú
Empresas privadas pueden comercializar tu idea sin reconocimiento
Universidades extranjeras pueden reclutar a competidores con tu propuesta

Qué hacer:

✅ Publica resultados preliminares en preprints (arXiv, bioRxiv) para establecer prioridad temporal
✅ Registra propiedad industrial si tu proyecto tiene potencial comercial (patentes)
✅ Documenta timeline de tu investigación (cuadernos de laboratorio con fecha)
⚖️ Si detectas plagio de tu proyecto, contacta con perito informático para análisis forense (timeline, evidencia publicación)

¿Qué es el Esquema Nacional de Seguridad (ENS)?

El Esquema Nacional de Seguridad (ENS) es el marco normativo de obligado cumplimiento para TODAS las administraciones públicas españolas en materia de ciberseguridad (Real Decreto 3/2010).

Objetivo: Garantizar seguridad de información tratada por administraciones públicas.

Niveles de Seguridad:

BAJO: Información sin datos personales (webs informativas)
MEDIO: Información con datos personales (DNI, IBAN, académicos) - OBLIGATORIO para becas/ayudas
ALTO: Información clasificada (defensa, seguridad nacional)

Controles por nivel:

BAJO: las medidas del anexo II en su nivel básico
MEDIO: las medidas del anexo II con los refuerzos propios de la categoría media
ALTO: las medidas del anexo II con los refuerzos de la categoría alta

Auditorías obligatorias: Cada 2 años por auditor externo acreditado CCN-CERT.

Sanciones incumplimiento: responsabilidad disciplinaria de los funcionarios y, si deriva en brecha, apercibimiento de la AEPD (art. 77 LOPDGDD) más responsabilidad patrimonial de la Administración.

¿Las administraciones pueden ser sancionadas por brechas de datos?

Están sujetas al RGPD igual que una empresa privada, pero su régimen sancionador es distinto. El art. 77 de la LOPDGDD establece que, cuando el responsable del tratamiento es una administración pública, la AEPD no impone la multa económica del art. 83 RGPD: dicta un apercibimiento, ordena las medidas correctoras necesarias y puede promover un procedimiento disciplinario contra el personal responsable. La responsabilidad económica no desaparece, pero circula por otras vías:

Responsabilidad patrimonial de la Administración frente a los ciudadanos perjudicados (art. 106 CE y Ley 40/2015): indemnización de los daños que se acrediten.
Responsabilidad penal de los funcionarios (art. 197 CP) por la revelación de datos reservados.
Responsabilidad disciplinaria del personal por no implementar las medidas del ENS.

Es un error frecuente —y caro en un escrito judicial— presentar «multas de la AEPD» a ayuntamientos o universidades públicas: esos expedientes se resuelven con apercibimiento, no con sanción pecuniaria.

¿Un perito puede auditar sistemas de mi administración pública?

SÍ, las administraciones públicas DEBEN contratar auditorías externas cada 2 años según ENS Art. 34.

Requisitos auditor ENS:

Acreditación CCN-CERT como auditor ENS (certificado oficial)
Experiencia demostrable en administraciones públicas
Conocimiento normativa: ENS + RGPD + Ley 40/2015 RJSP

Servicios auditoría disponibles:

Auditoría ENS bienal (obligatoria para categorías media y alta, art. 31 del RD 311/2022): verificación del cumplimiento de las medidas del anexo II
Pentesting especializado IDOR: Testing focalizado en control de acceso y autorización
Auditoría forense post-brecha: Análisis timeline ataque, vectores entrada, evidencia judicial
Formación desarrolladores: Secure Coding + OWASP Top 10 para equipos IT públicos

Coste orientativo:

Auditoría ENS completa: €15K-€50K según tamaño administración
Pentesting IDOR focalizado: €5K-€15K
Formación desarrolladores (2 días): €3K-€8K

Auditoría de seguridad conforme al ENS para tu administración

Auditoría de seguridad basada en el Esquema Nacional de Seguridad y detección de vulnerabilidades IDOR. Primera consulta gratuita.

Solicitar auditoría de seguridad

¿Cómo reporto una vulnerabilidad en un sistema público?

Proceso recomendado de revelación responsable:

Documentar la vulnerabilidad: capturas de pantalla, logs, prueba de concepto (PoC) técnica. NO exfiltres datos reales de ciudadanos.
Contactar con CCN-CERT: email a vulnerabilidades@ccn-cert.cni.es con descripción técnica detallada. Ellos coordinan con la administración afectada.
Plazo de respuesta: CCN-CERT debería responder en 48-72 h confirmando la recepción. La administración afectada debe responder en 7-14 días con un plan de remediación.
Revelación pública: NUNCA antes de 90 días desde el reporte (plazo estándar de la industria). Si la administración NO responde o NO soluciona, contactar con INCIBE o medios especializados.

IMPORTANTE: La legislación española NO protege explícitamente a investigadores seguridad (a diferencia de EE.UU. o UE). Por tanto:

❌ NO accedas a datos reales de ciudadanos (aunque sea posible)
❌ NO exfiltres información (aunque sea para demostrar gravedad)
✅ Reporta con PoC mínimo (demuestra vulnerabilidad sin explotar masivamente)

¿Qué hacer si sufro suplantación de identidad académica tras la brecha?

Pasos inmediatos si detectas alguien usando tus datos académicos:

Recopilar evidencia: capturas de pantalla de la suplantación (solicitud de beca con tu DNI, publicación con tu nombre pero no tuya, etc.). Preservar URLs, fechas y correos electrónicos.
Denunciar ante la Policía Nacional: denuncia por delito de suplantación de identidad (Art. 401 CP). Aporta la evidencia capturada y solicita el número de denuncia.
Notificar al Ministerio de Ciencia: email formal a protecciondatos@ciencia.gob.es exigiendo la cancelación de la solicitud fraudulenta. Adjuntar copia de la denuncia policial.
Análisis pericial forense: contactar con un perito informático para elaborar un informe pericial que pruebe: (1) el timeline brecha Ministerio → suplantación, (2) la evidencia digital con cadena de custodia y (3) los daños cuantificables.
Reclamación de daños: con el informe pericial, reclamar indemnización al Ministerio de Ciencia por responsabilidad patrimonial (Art. 106 CE), por el daño moral y patrimonial que se acredite.

Daños reclamables:

Daño moral: Ansiedad, estrés, tiempo perdido resolviendo suplantación
Daño patrimonial: Beca que NO obtuviste porque la consiguió el suplantador con tus datos
Lucro cesante: Oportunidades laborales/académicas perdidas por reputación dañada

Conclusión: Un Problema Sistémico Requiere Acción Sistémica

La oleada de ataques IDOR a administraciones públicas españolas en febrero 2026 (Hacienda, Ministerio Ciencia) NO es casualidad, es consecuencia de décadas de inversión insuficiente en ciberseguridad pública.

Las administraciones deben actuar AHORA:

✅ Auditoría extraordinaria de TODOS los sistemas con datos personales (no esperar ciclo bianual)
✅ Implementación rigurosa de controles ENS (dejar de ser papel mojado)
✅ Formación obligatoria desarrolladores en Secure Coding + OWASP
✅ Bug bounty programs públicos (recompensar investigadores que reportan vs criminalizar)
✅ Presupuesto ciberseguridad: mínimo 5% presupuesto IT (actualmente 1-3%)

La alternativa es clara: responsabilidad patrimonial ilimitada por los daños a los ciudadanos, responsabilidad penal y disciplinaria de los funcionarios responsables, y un coste reputacional incalculable.

Como perito informático forense, ofrezco auditorías ENS acreditadas y análisis forense post-brecha para administraciones públicas. Primera consulta gratuita para evaluar situación y necesidades específicas.

Consulta gratuita ciberseguridad administraciones públicas

Auditorías de seguridad conforme al ENS, pentesting IDOR y formación de desarrolladores. Primera videollamada sin coste ni compromiso.

Agendar consulta gratuita

Enlaces relacionados:

Referencias y fuentes

Hipertextual — Reporte inicial sobre el supuesto hackeo al Ministerio de Ciencia
Hackmanac — Verificación de credibilidad de la alerta de “ScienceLeaks”
CCN-CERT e INCIBE — Coordinación de la investigación forense del incidente
RGPD (UE) 2016/679 — Artículos 32 (medidas técnicas), 33 (notificación brechas 72h), 34 (notificación a interesados) y 82 (responsabilidad por daños)
Esquema Nacional de Seguridad (ENS) — Real Decreto 3/2010, artículos 3 y 34, controles op.acc.5, op.acc.6, op.exp.6
Código Penal español — Artículos 197.2 y 197.3 (revelación de secretos por funcionario público) y 401 (suplantación de identidad)
Ley 41/2002 — Protección de datos clínicos en investigación biomédica
OWASP Top 10 2021 — Referencia para formación de desarrolladores en seguridad de aplicaciones
ISO 27001 — Gestión de seguridad de la información
NIST Cybersecurity Framework — Mejores prácticas internacionales de ciberseguridad
Constitución Española, artículo 106 — Responsabilidad patrimonial de las administraciones públicas