Las bases de datos también hacen threat intelligence: cómo exprimir los incidentes que tu empresa ya registra

La paradoja es bastante elegante, si no fuera porque sale cara: muchas organizaciones compran feeds de inteligencia externos, contratan plataformas de detección cada vez más sofisticadas y, aun así, ignoran la fuente de señal más cercana que tienen delante de la nariz. Sus propias bases de datos de incidencias.

No hablo solo del SIEM, ni de un puñado de logs mal indexados, ni de ese ticketing donde se apilan avisos con títulos creativos como “fallo raro en servidor”. Hablo del conjunto de datos que una empresa ya genera cuando registra incidentes, alertas, cambios, accesos anómalos, vulnerabilidades, fraudes, errores operativos y eventos de terceros. Si ese material se estructura bien, deja de ser archivo histórico y se convierte en inteligencia accionable. Y aquí está el matiz que importa: no únicamente para detectar ataques, sino para priorizar riesgos, anticipar patrones, demostrar diligencia y sobrevivir a auditorías que cada vez preguntan menos por la política y más por la evidencia.

La idea no es nueva. Lo nuevo es que ahora empieza a ser inexcusable. Con DORA aplicable desde el 17 de enero de 2025, con NIS2 ya en fase de transposición y con obligaciones de notificación bajo GDPR art. 33 en 72 horas para violaciones de datos personales, seguir tratando las bases de datos como un vertedero de registros sale regulatoriamente caro. Y, operativamente, sale peor.

El problema no es almacenar incidentes; es que casi nadie los modela para aprender de ellos

La mayoría de organizaciones ya tiene varias bases de datos relevantes para ciberseguridad, aunque no siempre las llame así. Un gestor de tickets de SOC. Una CMDB. El repositorio de vulnerabilidades. El inventario de activos. Los logs del EDR. Los registros IAM. Los expedientes de fraude. El histórico de cambios en sistemas críticos. Incluso el correo de soporte, que suele ser una arqueología del desastre.

El fallo habitual no está en la ausencia de datos, sino en tres defectos muy concretos.

Primero, los datos se recogen con taxonomías pobres. Un incidente se clasifica como “malware”, otro como “sospecha de infección”, otro como “equipo lento” y otro como “comportamiento extraño”. Todo describe quizá la misma familia de hechos, pero la base de datos no lo sabe. Luego la organización pretende sacar tendencias con categorías que parecen inventadas en mitad de una guardia.

Segundo, los sistemas no se hablan. El ticket existe, pero no está vinculado al activo afectado. El activo existe, pero no está relacionado con su criticidad de negocio. La criticidad está en una hoja Excel distinta. El proveedor que administra el sistema figura en un contrato PDF. El usuario impactado aparece en otra herramienta. Resultado: mucho dato, poca inteligencia.

Tercero, se registra el “qué” pero no el “por qué” ni el “qué pasó después”. Sin causa raíz, sin tiempo de contención, sin dependencia tecnológica, sin vector de entrada, sin vinculación a una vulnerabilidad concreta, sin evidencia de si el incidente afectó a confidencialidad, integridad o disponibilidad. Eso sirve para cerrar tickets. No sirve para aprender.

Cuando una empresa dice que “quiere hacer threat intelligence”, a menudo lo que necesita antes es algo menos glamuroso y mucho más útil: disciplina de datos. Porque la inteligencia no aparece por arte de magia al comprar otra plataforma con dashboard azul oscuro y gráficos de severidad. Aparece cuando el dato interno se puede consultar, correlacionar y contrastar.

Qué convierte una BBDD de incidencias en una fuente de inteligencia de verdad

Una base de datos útil para ciberinteligencia no es la que acumula más registros. Es la que permite responder preguntas operativas con rapidez y con contexto. Por ejemplo:

• ¿Qué tipo de incidentes se repiten por unidad de negocio, tecnología, proveedor o geografía?
• ¿Qué activos críticos concentran más alertas y cuántas fueron falsos positivos?
• ¿Qué vulnerabilidades explotables se han correlacionado con incidentes reales y no solo con escaneos?
• ¿Qué terceros aparecen de forma recurrente en eventos con impacto operativo?
• ¿Cuánto tiempo transcurre entre la detección, la contención, la erradicación y la recuperación?
• ¿Qué patrones precedieron a incidentes relevantes en los últimos 12 meses?

Si tu base de datos no permite eso, tienes archivo. No inteligencia.

La estructura mínima debería unir al menos siete dimensiones: fecha y hora, activo afectado, criticidad del activo, vector o causa inicial, tipo de impacto, tercero implicado y tiempos de respuesta. A partir de ahí gana muchísimo valor añadir normalización MITRE ATT&CK para técnicas observadas, referencias CVE si hay explotación de vulnerabilidades, usuario o rol comprometido, nivel de privilegio afectado y una clasificación de datos impactados cuando exista componente de privacidad.

El detalle importa. No es lo mismo registrar “acceso anómalo” que “acceso exitoso desde ubicación no habitual con MFA fatigado, cuenta con privilegios elevados y posterior creación de regla de reenvío”. Lo primero engorda estadísticas. Lo segundo da pie a controles, hipótesis de hunting y alertas reutilizables.

También conviene diferenciar entre evento, alerta, incidente e incidente material. Parece semántica, pero no lo es. DORA, en sus artículos 17 a 23, separa la gestión, clasificación y notificación de incidentes relacionados con las TIC, y exige criterios para determinar la gravedad y el impacto. Si mezclas ruido con incidentes materialmente relevantes, terminarás con indicadores inútiles y con un proceso de escalado que castiga al equipo cada vez que suena cualquier cosa.

La señal escondida: por qué el histórico interno vale más de lo que parece

Los feeds externos son útiles. Dan campañas, IOCs, TTPs, actores y tendencias sectoriales. Pero la señal interna tiene una ventaja que ningún proveedor puede venderte: sabe cómo atacan a tu organización de verdad, no cómo atacan “al mercado”.

Eso cambia la priorización. Una CVE con puntuación CVSS 9.8 puede ser teóricamente crítica y, sin embargo, irrelevante en tu entorno si no existe exposición explotable. Al revés, una debilidad aparentemente menor puede ser recurrente en tus incidentes porque coincide con un patrón real: privilegios excesivos, APIs mal autenticadas, cuentas de servicio inmortales, segmentación decorativa o integraciones heredadas que nadie quiere tocar.

Las BBDD históricas permiten extraer cuatro tipos de inteligencia que suelen infrautilizarse.

1. Inteligencia de recurrencia

Identifica qué vuelve una y otra vez. No el gran incidente de portada, sino la misma clase de error que reaparece cada trimestre. Misma unidad. Mismo proveedor. Mismo control débil. Las organizaciones maduras no solo cuentan incidentes; cuentan reincidencias por causa raíz. Es una diferencia enorme.

2. Inteligencia de impacto real

Muchas prioridades de ciberseguridad se deciden por miedo reputacional o por severidades teóricas. El histórico interno permite saber qué vectores han causado de verdad indisponibilidad, fraude, fuga de datos o interrupción del negocio. Eso afina inversiones mejor que cualquier presentación de ventas.

3. Inteligencia de dependencia

Los incidentes enseñan dónde están las dependencias críticas aunque el inventario oficial no lo admita. Si un fallo en un proveedor SaaS acaba afectando a autenticación, atención al cliente, reporting regulatorio y operaciones de back office, ya tienes un mapa de concentración de riesgo mucho más honesto que el del PowerPoint de gobernanza.

4. Inteligencia de velocidad

El tiempo es un dato infraexplotado. Tiempo de detección. Tiempo de escalado. Tiempo hasta aislar un activo. Tiempo hasta restaurar un servicio. En DORA, la resiliencia operativa no se demuestra con adjetivos, sino con capacidad medible. Tu BBDD debería poder decir si mejoras o empeoras. Y no, “estamos reforzando procesos” no es una métrica.

Del ticket al patrón: el modelo de datos que marca la diferencia

Si una organización quiere usar sus BBDD como motor de inteligencia, tiene que tratar el diseño del dato como una pieza de seguridad, no como un apéndice administrativo. La pregunta correcta no es “qué campos metemos”, sino “qué decisiones críticas queremos poder tomar dentro de seis meses”.

Un modelo razonable suele incluir estos bloques:

Identificación del incidente

ID único, fecha de detección, fecha de inicio estimada, fuente de detección, equipo responsable, severidad inicial y severidad final. La diferencia entre severidad inicial y final revela mucho sobre la calidad del triage.

Contexto tecnológico

Activo, propietario del activo, entorno afectado, proveedor implicado, región o centro de datos, dependencia con procesos críticos y exposición externa o interna. Si el activo no está vinculado a negocio, media película ya la has perdido.

Táctica y vector

Vector de entrada, técnica ATT&CK, vulnerabilidad explotada con referencia CVE si procede, credencial comprometida, error humano, tercero, fallo de configuración o abuso de privilegios. Cuanto más normalizada esté esta capa, mejor funcionarán las consultas longitudinales.

Impacto

Disponibilidad, integridad, confidencialidad, impacto financiero estimado, clientes afectados, datos personales involucrados, obligación regulatoria potencial, necesidad de notificación y nivel de materialidad. Para GDPR art. 33 y art. 34, por ejemplo, no basta con saber que hubo “incidente”; necesitas evaluar si existió violación de seguridad de datos personales y si genera riesgo o alto riesgo para los interesados.

Respuesta

Medidas de contención, tiempo de contención, erradicación, recuperación, lecciones aprendidas, causa raíz y control correctivo. Parece básico. Sorprendentemente, aquí es donde más agujeros aparecen.

Este modelo no tiene que vivir en una sola herramienta. Puede repartirse entre SIEM, SOAR, GRC, CMDB y ticketing. Pero sí necesita una capa de integración. Sin ella, lo que tienes no es inteligencia distribuida. Es fragmentación con presupuesto.

Qué relación tiene esto con DORA, NIS2 y GDPR: más de la que muchos equipos quieren admitir

Conviene pinchar una burbuja frecuente: extraer inteligencia de las BBDD internas no es solo una buena práctica técnica. Cada vez más, es la base fáctica para cumplir expectativas regulatorias.

En DORA, el artículo 10 obliga a disponer de marcos sólidos de gestión del riesgo de las TIC, con mecanismos para detectar anomalías y gestionar incidentes. Los artículos 17 y 18 exigen procesos de gestión, clasificación y registro de incidentes relacionados con las TIC, y el artículo 19 trata de la notificación de incidentes graves. Traducido al castellano no ceremonial: si una entidad no es capaz de estructurar datos consistentes sobre sus incidentes, sufrirá al clasificar, reportar y demostrar capacidad de aprendizaje.

El artículo 28 de DORA, sobre la gestión del riesgo de terceros proveedores de servicios TIC, también entra aquí de lleno. Si tu base de incidentes no captura de forma consistente cuándo aparece un tercero, en qué servicio, con qué criticidad y con qué impacto, no podrás defender una supervisión seria de terceros críticos. Luego llegarán las prisas cuando el regulador pregunte por concentración, salidas contractuales o dependencia operativa.

NIS2 aprieta por otra vía. El artículo 21 exige medidas técnicas, operativas y organizativas apropiadas y proporcionadas para gestionar riesgos de seguridad. Entre ellas, gestión de incidentes, continuidad, seguridad en la cadena de suministro, evaluación de eficacia y prácticas básicas de ciberhigiene. Todo eso requiere evidencia operativa. No basta con una política bonita en PDF. Si un operador esencial o importante no puede demostrar qué incidentes sufrió, qué patrones identificó y qué controles reforzó, la conversación con la autoridad competente se volverá incómoda deprisa.

Y luego está GDPR, que muchos equipos de seguridad siguen tratando como si solo fuera asunto del DPO. Error clásico. El artículo 33 obliga a notificar violaciones de seguridad de datos personales a la autoridad de control sin dilación indebida y, cuando sea posible, en un máximo de 72 horas desde que se tuvo constancia. El artículo 34 obliga, en ciertos casos, a comunicar a los afectados. Sin un repositorio de incidentes con campos claros sobre categorías de datos, volumen potencial, sistemas afectados, medidas aplicadas y evaluación de riesgo, esas 72 horas se convierten en una carrera con los cordones atados.

La conclusión práctica es incómoda pero útil: una base de incidentes mal diseñada no solo empeora la defensa. También deteriora el cumplimiento.

La trampa más común: confundir observabilidad con inteligencia

Hay organizaciones con una observabilidad excelente y una inteligencia pobre. Sí, las dos cosas pueden coexistir.

Tienen millones de eventos al día, dashboards de latencia, métricas de endpoint, telemetría de nube, detecciones de identidad, logs de API y alertas automatizadas a todas horas. Eso está muy bien. Pero si no pueden responder qué causas raíz se repiten en sus activos críticos, qué proveedores concentran más incidencias materiales o qué controles correctivos redujeron realmente el riesgo, no están haciendo inteligencia. Están contemplando el incendio con resolución 4K.

La inteligencia exige contexto, correlación y decisión. Y exige memoria institucional. El histórico importa porque reduce uno de los males más subestimados del sector: aprender dos veces la misma lección.

Un ejemplo sencillo. Supón que una empresa registra durante doce meses múltiples incidentes menores vinculados a restablecimientos de MFA por ingeniería social en soporte. Ninguno, por sí solo, parece catastrófico. Pero el patrón revela una debilidad estructural en el proceso de verificación de identidad. Esa señal interna vale oro. Es exactamente el tipo de precursor que puede evitar un compromiso mayor de cuentas privilegiadas meses después.

Sin base de datos bien explotada, esos incidentes pasan como anécdotas. Con una base útil, se convierten en un argumento irrefutable para cambiar controles, formar a soporte, endurecer el proceso de recovery y ajustar detecciones.

Lo que sí deberían hacer CISO, SOC y compliance para extraer valor real

El trabajo serio empieza bastante antes de lanzar algoritmos o hablar de IA. Si el dato está desordenado, la automatización solo escala el desorden. Bastante tenemos ya con eso.

Hay cinco decisiones operativas que marcan la diferencia.

Normalizar taxonomías antes de pedir analítica avanzada

No hace falta inventar una ontología futurista. Hace falta reducir ambigüedad. Define categorías cerradas para tipo de incidente, vector, impacto, tercero implicado, criticidad del activo y resultado final. Si una misma realidad puede etiquetarse de cinco formas distintas, la base se vuelve políticamente correcta pero analíticamente inútil.

Usar marcos conocidos ayuda. MITRE ATT&CK para técnicas, CVE/CVSS para vulnerabilidades, y un esquema interno de materialidad alineado con notificación regulatoria. No porque quede sofisticado, sino porque permite comparar y hablar un idioma operativo común.

Unir seguridad, operaciones, legal y privacidad sobre el mismo registro

El mismo incidente genera preguntas distintas. Seguridad quiere saber vector, persistencia y contención. Operaciones, disponibilidad y recuperación. Legal, obligaciones de notificación. Privacidad, categorías de datos y riesgo a interesados. Si cada equipo crea su repositorio paralelo, la organización multiplica versiones de la verdad. Mala idea, especialmente cuando toca reportar.

La solución no es que todos trabajen en la misma pantalla, sino que compartan identificadores, campos troncales y reglas de actualización. Un incidente, una historia coherente.

Capturar tiempos de respuesta de forma fiable

MTTD, MTTR y métricas parecidas han sido abusadas hasta el agotamiento, pero bien usadas siguen siendo valiosas. El problema es cuando se maquillan o no están definidas igual en todos los equipos. ¿Detección es la primera alerta automática o el momento en que un analista confirma el incidente? ¿Recuperación es restaurar el servicio mínimo o cerrar el expediente? Sin definiciones sólidas, la métrica es cosmética.

DORA, de nuevo, empuja a profesionalizar esto. Y el mercado asegurador también. Quien aspire a demostrar madurez o negociar mejor determinadas coberturas necesita series temporales creíbles, no cifras ceremoniales.

Relacionar incidentes con terceros y activos críticos

Este punto merece insistencia. Muchas empresas saben que tienen riesgo de terceros, pero no pueden demostrar cómo se materializa. Ocurre algo curioso: el área de procurement guarda contratos, seguridad guarda alertas y negocio sufre las interrupciones, pero nadie consolida la película completa.

Relacionar cada incidente con el tercero implicado, el servicio prestado, la criticidad del proceso afectado y el impacto real cambia la conversación. Ahí aparecen dependencias invisibles, concentraciones de riesgo y proveedores aparentemente secundarios que sostienen medio negocio.

No borrar el matiz humano de los datos

Las bases de datos tienden a comprimir la realidad en campos discretos. Útil, sí. Suficiente, no siempre. Mantener un espacio estructurado para narrativa breve, causa raíz y lección aprendida evita que la analítica pierda contexto. Un buen modelo combina normalización con una dosis razonable de explicación humana.

Qué papel puede jugar la IA y dónde empieza el humo

Hablar de convertir BBDD en inteligencia y no mencionar IA sería raro. Hablar de IA como si resolviera el problema por sí sola sería peor.

La IA puede ayudar en al menos cuatro tareas concretas: clasificar incidentes con taxonomías consistentes, resumir expedientes largos, sugerir correlaciones entre eventos aparentemente dispersos y detectar anomalías históricas en series temporales. Eso tiene valor real, sobre todo en entornos con mucho volumen y equipos saturados.

Pero hay una condición previa bastante antipática para el hype: datos limpios, permisos bien gobernados y criterios de validación humana. Si el histórico está plagado de categorías incoherentes, descripciones vagas y datos sensibles mal etiquetados, el modelo aprenderá exactamente eso. La basura, ahora amplificada.

Además, si se van a usar modelos para procesar registros que incluyan datos personales, aparecen preguntas serias de minimización, base jurídica, control de acceso y retención. GDPR no desaparece porque el proyecto se llame “copiloto de seguridad”. Y si el sistema genera recomendaciones que afectan a priorización o escalado, conviene documentar límites, supervisión humana y calidad del dato de entrenamiento. El AI Act, aunque no haya sido concebido específicamente para SOC internos, ha vacunado a muchos equipos contra la ingenuidad regulatoria de “ya veremos después”.

La IA sirve. El humo también existe. La diferencia suele estar en una pregunta simple: ¿el sistema mejora decisiones concretas y medibles o solo produce resúmenes más bonitos?

Los errores que más dinero cuestan cuando se intenta explotar una BBDD de seguridad

Hay tropiezos bastante previsibles. Lo llamativo es que se sigan repitiendo.

Uno: querer centralizarlo todo de golpe. Integrar SIEM, EDR, IAM, vulnerabilidades, ticketing, CMDB, cloud posture, correo, fraude y terceros en una única capa perfecta suele acabar en un programa larguísimo, caro y con resultados tardíos. Funciona mejor empezar por los activos críticos y los tipos de incidentes con más impacto regulatorio u operativo.

Dos: medir volumen en lugar de utilidad. Más incidentes registrados no significa más madurez. A veces significa que la clasificación empeoró o que el ruido subió. La pregunta relevante no es cuántos registros tienes, sino cuántas decisiones mejores te permiten tomar.

Tres: no gobernar el ciclo de vida del dato. Retención indefinida, duplicados, campos libres sin control, cambios de taxonomía sin trazabilidad y accesos excesivos convierten la base en un riesgo en sí misma. Si allí confluyen datos técnicos, información de empleados, evidencias forenses y datos de clientes, la gobernanza deja de ser una molestia administrativa. Es una obligación de seguridad.

Cuatro: no cerrar el bucle con remediación. El mayor pecado no es carecer de dashboards; es no traducir patrones en controles correctivos. Una BBDD brillante que no cambia configuraciones, procesos o contratos sirve para impresionar en comité. Y poco más.

Un caso típico: del histórico de tickets a decisiones de seguridad más finas

Pensemos en una entidad mediana con operaciones en nube híbrida, atención al cliente digital y varios proveedores de software empresarial. Durante un año ha registrado 1.800 incidentes y alertas escaladas, de los cuales 140 terminaron como incidentes confirmados y 11 causaron impacto operativo relevante. A primera vista, la cifra cuenta poco.

Cuando cruza esos datos con activos críticos, descubre que 7 de los 11 incidentes relevantes afectaron a sistemas integrados con el mismo proveedor de identidad. Cuando añade tiempos de respuesta, ve que los incidentes vinculados a ese proveedor tardaron un 60% más en contenerse por falta de visibilidad contractual y dependencia del soporte externo. Cuando revisa causa raíz, encuentra tres patrones: fatiga MFA, errores en procesos de recovery de cuenta y privilegios excesivos en integraciones heredadas.

Eso ya no es “histórico”. Es inteligencia. Con ese análisis, la entidad puede renegociar cláusulas de soporte, revisar segregación de privilegios, reforzar procedimientos de verificación de identidad y ajustar alertas específicas. También puede defender ante auditoría por qué priorizó esos controles y no otros. Esa trazabilidad vale mucho más que un listado de buenas intenciones.

En entidades sujetas a DORA, además, el ejercicio mejora la capacidad de registrar, clasificar y escalar incidentes relacionados con terceros TIC. Y si alguno implica datos personales, la evaluación para GDPR deja de depender de reconstrucciones improvisadas.

Qué indicadores merecen la pena y cuáles son puro teatro

No hacen falta cincuenta KPIs. De hecho, cuantos más se coleccionan, más fácil es perder de vista lo importante. Un cuadro de mando útil para explotar una BBDD de incidentes debería centrarse en unos pocos indicadores vinculados a decisiones.

Entre los más útiles suelen estar la recurrencia por causa raíz, el porcentaje de incidentes en activos críticos, el tiempo de contención por tipo de incidente, la proporción asociada a terceros, el volumen con implicación de identidad o privilegios y la tasa de reapertura o reincidencia tras remediación. Eso revela si el sistema aprende o simplemente registra.

En cambio, métricas como “número total de alertas procesadas” o “porcentaje de tickets cerrados en plazo” pueden ser necesarias para gestión operativa, pero no bastan para inteligencia. Se pueden cumplir y seguir sin entender nada.

Una señal de madurez interesante es medir cuántos controles correctivos nacen del análisis histórico y si reducen incidentes comparables en trimestres posteriores. Ahí se ve si la base de datos está alimentando decisiones o solo informes.

La pieza que casi siempre falta: gobierno del dato

Convertir las BBDD en inteligencia no es solo un proyecto del SOC. Requiere gobierno del dato con bastante más seriedad de la que muchas áreas de seguridad quisieran admitir.

¿Quién define la taxonomía? ¿Quién aprueba cambios? ¿Qué campos son obligatorios para cerrar un incidente? ¿Qué calidad mínima se exige? ¿Cuánto tiempo se conservan los expedientes? ¿Quién puede acceder a narrativas que contengan información sensible? ¿Cómo se anonimiza o minimiza cuando toca? ¿Qué pasa cuando un proveedor aporta evidencias que deben integrarse?

Sin esas reglas, la base crecerá, sí, pero también se degradará. Y una base degradada es traicionera: parece una fuente de verdad hasta que intentas usarla en una crisis o en una inspección.

Aquí privacidad y seguridad tienen que dejar de actuar como primos que solo se llaman en Navidad. Si los registros incluyen identificadores, trazas de actividad de empleados, contenidos de correo, direcciones IP, evidencias forenses o datos de clientes, entran principios de minimización, limitación de finalidad, control de acceso y retención. Eso no impide explotar la base. Obliga a hacerlo bien.

Lo que viene ahora: menos fascinación por la telemetría, más exigencia de evidencia

El mercado de seguridad ha vivido años obsesionado con ver más. Más logs, más señales, más superficie, más cobertura. Esa fase no ha terminado, pero el péndulo se está moviendo. Reguladores, auditores, consejos y aseguradoras empiezan a pedir otra cosa: demostrar que la organización entiende sus incidentes, aprende de ellos y toma decisiones trazables.

Esa es la razón por la que las bases de datos internas están pasando de ser un residuo administrativo a un activo estratégico. No porque alguien haya redescubierto el valor del dato —esa frase ya viene muy amortizada—, sino porque la presión operativa y regulatoria obliga a ello.

La noticia de fondo, por tanto, no es que las BBDD puedan generar inteligencia. Pueden, claro. La noticia es que seguir sin hacerlo empieza a parecer negligencia organizativa con UI corporativa.

Si tu empresa ya registra incidentes, vulnerabilidades, accesos y eventos de terceros, la materia prima existe. La pregunta no es tecnológica. Es casi más incómoda: ¿tu organización quiere de verdad aprender de sus incidentes, o solo archivarlos para que molesten menos?

Aquí está el quid. El dato histórico no sustituye al threat intelligence externo, al hunting ni a la detección avanzada. Pero sí les da algo que a menudo les falta: contexto propio, memoria y prioridades reales. Y en seguridad, como en casi todo, la inteligencia útil no es la más ruidosa. Es la que cambia decisiones antes del siguiente incidente.