Detección en ciberseguridad en 2026: fusión de telemetría, eBPF, CNAPP y analítica basada en comportamiento para reducir el tiempo de permanencia del adversario

1. Introducción

La detección es el núcleo operativo de cualquier programa serio de ciberseguridad. Mientras la prevención intenta impedir el acceso inicial, la detección busca identificar, contextualizar y contener la actividad adversaria que inevitablemente atraviesa controles perimetrales, credenciales robadas, software de terceros comprometido o configuraciones débiles. En 2026, esta realidad es más evidente que nunca: los atacantes ya no dependen exclusivamente de malware tradicional, sino de una combinación de abuso de identidades, ejecución remota, herramientas administrativas legítimas, servicios en la nube, automatización asistida por IA y tácticas de baja visibilidad diseñadas para mezclarse con la operación normal. Por ello, la detección no puede tratarse como una capa secundaria; debe concebirse como un sistema de inferencia distribuido, con visibilidad transversal y capacidad de respuesta casi en tiempo real.

La evolución histórica de la detección muestra una transición clara desde modelos reactivamente sintácticos hacia modelos contextuales y probabilísticos. Los antivirus basados en firmas funcionaban razonablemente bien frente a familias de malware recurrentes, pero fracasaban ante empaquetadores, polimorfismo y carga útil sin archivo. Las reglas IDS/IPS ayudaron a capturar explotación conocida, pero su alcance se degradó rápidamente cuando los adversarios adoptaron TLS, DNS tunelizado, protocolos legítimos y abuso de servicios web. Con la consolidación del teletrabajo, la adopción masiva de SaaS y la migración a arquitecturas híbridas, el perímetro desapareció como entidad única. La detección pasó entonces a depender de correlación entre endpoints, identidad, red, nube y postura de configuración, con mayor atención a la secuencia de acciones que al contenido aislado de un paquete o binario.

En 2026, la complejidad de la detección se incrementa por tres factores. Primero, la expansión de superficies observables: EDR, NDR, XDR, CNAPP, CSPM, CIEM, SASE, CASB, controles de identidad y telemetría de aplicación generan volúmenes masivos de eventos heterogéneos. Segundo, la sofisticación operativa del adversario: el uso de living-off-the-land binaries (LOLBins), comandos nativos de PowerShell, WMI, rundll32, regsvr32, mshta, binarios firmados y herramientas de post-explotación convierte la detección en un problema de análisis de contexto y secuencia. Tercero, la asimetría económica: un atacante puede invertir horas en reconocimiento y preparación para ejecutar una campaña que obligue a defender con latencias de segundos o minutos. Esta desproporción exige un diseño de detección que minimice el tiempo medio de identificación $MTTD$ y el tiempo medio de contención $MTTC$, no solo la tasa de aciertos.

La formalización práctica del problema puede expresarse como una decisión binaria o multiclase sobre una secuencia de observaciones. Sea $X = {x_1, x_2, \dots, x_n}$ una secuencia temporal de eventos y $Y \in {0,1,\dots,k}$ una etiqueta de estado, donde $0$ representa comportamiento benigno y los demás valores denotan familias o etapas de ataque. El objetivo es estimar $P(Y \mid X, C)$, donde $C$ agrupa contexto operativo, criticidad del activo, identidad, segmento de red, postura de seguridad y señales históricas. La dificultad no está solo en clasificar eventos aislados, sino en estimar dependencias de largo alcance y minimizar el costo operativo de errores. En entornos reales, un falso positivo de bajo contexto puede erosionar la confianza del analista, mientras un falso negativo puede habilitar exfiltración, sabotaje o ransomware.

Este trabajo sostiene que la detección moderna debe abandonar la dicotomía simplista entre firmas y anomalías. Las firmas siguen siendo útiles cuando representan comportamientos estables de alta precisión; sin embargo, la cobertura de técnicas emergentes y la adaptabilidad del adversario requieren analítica basada en comportamiento, grafos temporales, enriquecimiento de identidad y validación de hipótesis contra marcos tácticos como ATT&CK. La contribución principal es un marco de detección híbrido, operativo y explicable, orientado a producción, que integra reglas, modelos estadísticos, telemetría de bajo nivel y correlación entre dominios. La premisa central es que la defensa no debe intentar “adivinar malware”, sino reconocer trayectorias adversarias.

La motivación es también organizacional. Muchas organizaciones acumulan herramientas, pero carecen de un modelo de detección unificado. Tienen EDR en endpoints, logs en un SIEM, alertas en la nube, reglas de identidad y decenas de dashboards desconectados. El resultado es una visión fragmentada que favorece el ruido y castiga la priorización. El problema de fondo es de arquitectura y de modelado, no únicamente de volumen de datos. La detección eficaz en 2026 requiere un lenguaje común entre telemetría, hipótesis, respuesta y riesgo. Sin esta integración, incluso una infraestructura costosa produce alertas tardías, inconsistentes o imposibles de accionar.

En consecuencia, este artículo propone una visión integral de la detección como disciplina técnico-operacional. Se analizan antecedentes, se formaliza el problema, se describe una metodología híbrida y se presenta una implementación de referencia con herramientas reales y vigentes hasta 2026. La evaluación experimental se centra en latencia, cobertura, precisión, costo de mantenimiento y utilidad operacional, porque en seguridad la métrica relevante no es solo académica sino táctica: ¿la detección interrumpe la cadena de ataque antes de que el adversario logre persistencia, movimiento lateral, acceso a secretos o cifrado?

2. Antecedentes y trabajos relacionados

La literatura sobre detección en ciberseguridad es amplia y evolutiva. Los trabajos tempranos se centraron en detección basada en firmas, donde el problema se reduce a comparar un evento o payload con patrones conocidos. Este enfoque, propio de antivirus y IDS clásicos como Snort y Suricata, ofrecía alta precisión para amenazas previamente catalogadas, pero sufre ante evasión trivial y no generaliza a variantes nuevas. A nivel conceptual, el valor de las firmas sigue vigente porque muchas tácticas adversarias presentan invariantes observables: nombres de servicio, cadenas de comandos, secuencias de API, rutas de persistencia o combinaciones de flags. Sin embargo, depender exclusivamente de firmas es insuficiente frente a adversarios que reempaquetan, ofuscan o reencadenan acciones legítimas.

La segunda gran familia corresponde a la detección por anomalías. Desde los trabajos clásicos de modelado estadístico y aprendizaje no supervisado hasta las arquitecturas modernas de autoencoders, isolation forests y clustering temporal, la idea es identificar desviaciones respecto al comportamiento normal. Esta aproximación es atractiva porque no depende de conocimiento exhaustivo del ataque. No obstante, en entornos corporativos presenta desafíos serios: deriva conceptual, heterogeneidad de usuarios y servicios, picos de actividad legítima, y dificultad de explicar por qué un evento fue marcado como anómalo. En la práctica, los modelos puramente anómalos pueden ser útiles como señales de priorización, pero raramente deben operar solos.

La tercera línea, consolidada durante la última década, es la detección basada en comportamiento y secuencias TTP. Aquí la unidad de análisis no es un evento aislado sino la trayectoria: enumeración, acceso a credenciales, ejecución remota, persistencia, exfiltración o cifrado. El marco MITRE ATT&CK ha sido central para esta evolución, al proporcionar taxonomía compartida de tácticas y técnicas. El valor de ATT&CK no reside solo en clasificación, sino en permitir cobertura, gap analysis, validación de controles y comunicación entre detección y respuesta. La adopción de ATT&CK favoreció el desarrollo de reglas Sigma, mapeos a queries de SIEM, emulación adversaria con Caldera y validación con Atomic Red Team.

Tabla 1. Evolución de enfoques de detección

Enfoque	Unidad de análisis	Ventaja principal	Limitación principal	Herramientas representativas
Firmas	Hash, cadena, patrón de red	Alta precisión en amenazas conocidas	Baja generalización	Snort, Suricata, YARA, AV
Anomalías	Distribuciones, outliers	Descubre desviaciones nuevas	Falsos positivos y deriva	Isolation Forest, autoencoders
Comportamiento	Secuencias TTP	Mejor cobertura táctica	Requiere contexto y correlación	ATT&CK, Sigma, EDR, XDR
Grafos temporales	Relación entre entidades	Modela movimiento lateral y abuso de identidad	Complejidad operativa	Neo4j, graph analytics
Detección híbrida	Multifuente	Equilibrio entre precisión y cobertura	Integración difícil	SIEM, SOAR, CNAPP, eBPF

La adopción de EDR cambió el plano de observabilidad al capturar procesos, árboles de ejecución, módulos cargados, conexiones de red, manipulaciones de memoria y llamadas sensibles. A su vez, la expansión de NDR aportó visibilidad del tráfico lateral y saliente, especialmente relevante para detectar beaconing, túneles DNS, C2 sobre HTTPS y patrones de exfiltración. La nube introdujo CNAPP, CSPM e CIEM, que permiten detectar configuraciones inseguras, privilegios excesivos y eventos de API. Junto con esto, eBPF emergió como una capa de instrumentación de bajo overhead para Linux, ofreciendo observabilidad precisa de syscalls, conexiones y comportamiento de procesos, especialmente valiosa en clusters Kubernetes y plataformas cloud-native.

Tabla 2. Comparación de fuentes de telemetría relevantes en 2026

Fuente	Cobertura	Resolución temporal	Costo operacional	Riesgo de ceguera
EDR	Endpoint, proceso, memoria	Alta	Medio-alto	Bajo en hosts cubiertos
NDR	Red, flujo, TLS, DNS	Media-alta	Medio	Medio si hay cifrado/endpoints opacos
SIEM	Agregación multifuente	Depende del pipeline	Alto	Alto si faltan fuentes
CNAPP	Nube, identidad, configuración	Media	Medio	Medio en SaaS y shadow IT
eBPF	Kernel, syscalls, sockets	Muy alta	Medio-bajo	Bajo en Linux modernos
IAM/IdP logs	Identidad, MFA, sesiones	Alta	Bajo-medio	Medio si hay federación compleja

Otra línea de trabajo relevante es la detección basada en emulación adversaria y validación continua. Herramientas como Atomic Red Team, Caldera, Prelude Operator y, en plataformas comerciales, BAS (Breach and Attack Simulation), permiten ejecutar TTPs controlados para verificar si una regla o modelo realmente detecta un comportamiento esperado. Este enfoque es particularmente útil porque evita la ilusión de cobertura: una regla existe en el SIEM, pero si nunca dispara en una emulación realista, su valor es dudoso. La detección efectiva debe ser verificable por pruebas repetibles, no solo por revisión estática.

En la literatura reciente también creció el interés en detección asistida por modelos de lenguaje y análisis semántico. En 2026, estos sistemas se usan con cautela para triage, explicación de alertas, generación de hipótesis y normalización de logs. Sin embargo, su rol en detección primaria sigue siendo delicado por problemas de alucinación, consistencia y seguridad de prompt. Por ello, los despliegues maduros suelen limitar su función a asistencia analítica y nunca a decisión autónoma sin controles. La seguridad de LLM introduce además vectores propios: prompt injection, exfiltración por contexto, abuso de herramientas y manipulación de agentes. Todo esto alimenta nuevos requisitos para la detección, incluyendo monitorización de conversaciones, acciones de herramientas y salidas de modelos.

Finalmente, la relación entre detección y defensa moderna exige considerar estándares y marcos como NIST SP 800-61, NIST SP 800-53, MITRE D3FEND y los principios de zero trust. La detección ya no es una función aislada del SOC; es un componente transversal de arquitectura, identidad, endpoint, nube y respuesta. En esta convergencia, el reto principal no es la falta de alertas, sino la dificultad de convertir telemetría en decisiones oportunas y defendibles.

3. Modelo de amenaza y formalización del problema

El modelo de amenaza considerado es el de un adversario racional, persistente y adaptativo, capaz de combinar acceso inicial por phishing, explotación de borde, abuso de credenciales, cadenas de suministro o vulnerabilidades en servicios expuestos. Se asume que el atacante busca uno o más objetivos: persistencia, escalada de privilegios, movimiento lateral, acceso a secretos, exfiltración, sabotaje o despliegue de ransomware. También se asume que emplea herramientas legítimas del sistema, canales cifrados y, cuando conviene, automatización con IA para generar variaciones de comandos, correos de phishing, payloads o mensajes de ingeniería social.

Desde la perspectiva de detección, el problema puede formalizarse como una inferencia sobre observaciones heterogéneas. Sea un sistema observado por entidades $E = {e_1, e_2, \dots, e_m}$, donde cada entidad puede ser un usuario, host, contenedor, proceso, dirección IP, sesión cloud o cuenta de servicio. Para cada entidad, observamos eventos $x_t$ con tiempo $t$, atributos $\phi(x_t)$ y contexto $c_t$. La tarea consiste en estimar la probabilidad de que una secuencia pertenezca a una cadena maliciosa: $$ P(\text{malicioso} \mid x_{1:n}, c_{1:n}) = \sigma(f(x_{1:n}, c_{1:n})) $$ donde $f$ es un puntaje de riesgo o clasificador y $\sigma$ representa una transformación logística o una normalización probabilística.

La detección práctica rara vez es binaria. En entornos de producción, conviene modelarla como un problema de priorización. Definimos un puntaje total: $$ R = \alpha P_m + \beta I + \gamma E + \delta A - \lambda F $$ donde $P_m$ es la probabilidad de malicia, $I$ la criticidad del activo, $E$ la exposición, $A$ la anomalía contextual y $F$ el costo esperado de falso positivo. Los coeficientes $\alpha,\beta,\gamma,\delta,\lambda$ se calibran según apetito de riesgo y capacidad operativa del SOC. Esta formulación refleja una realidad importante: una alerta no vale lo mismo en un controlador de dominio, un servidor de CI/CD, una cuenta de break-glass o una laptop de bajo privilegio.

Tabla 3. Variables de riesgo relevantes para priorización

Variable	Descripción	Ejemplo de fuente	Impacto en detección
$P_m$	Probabilidad de actividad maliciosa	Modelo, regla, correlación	Determina la señal base
$I$	Criticidad del activo	CMDB, tagging cloud, IAM	Eleva prioridad en activos sensibles
$E$	Exposición	Internet-facing, VPN, SaaS	Aumenta probabilidad de compromiso
$A$	Anomalía contextual	Baseline, peer group	Identifica desviaciones relevantes
$F$	Costo de falso positivo	Historial SOC, SLA	Evita saturación de analistas

El problema incluye además restricciones de observabilidad. No todos los sistemas generan telemetría suficiente; algunos endpoints están cifrados, otros carecen de agentes, y algunos servicios SaaS solo exponen logs parciales. Por ello, la detección se define sobre un conjunto incompleto de observaciones $\tilde{X}$, con posibles pérdidas, retrasos o duplicados. Esto obliga a diseñar algoritmos robustos frente a missingness y asimetría entre dominios. En un cluster Kubernetes, por ejemplo, la combinación de eBPF, audit logs, registros de API server y telemetría de red puede revelar secuencias de abuso de pods privilegiados, mientras que sin alguna de estas fuentes la observación se vuelve ambigua.

El adversario moderno también intenta explotar el propio sistema de detección. Puede generar ruido para esconderse, inducir fatiga en el SOC, manipular logs, borrar evidencias o abusar de cuentas de servicio para parecer legítimo. Esto introduce un juego adversarial donde la defensa debe anticipar evasión semántica y camuflaje operacional. La detección, por tanto, debe ser resistente a manipulación y no depender de un único indicador. El principio operativo es claro: cuanto más crítica sea la acción del atacante, más fuentes independientes deberían corroborarla.

En términos de métricas, la evaluación no debe limitarse a precisión y recall. El objetivo es minimizar: $$ \text{Costo total} = C_{FN}\cdot FN + C_{FP}\cdot FP + C_D\cdot D + C_O\cdot O $$ donde $FN$ es falso negativo, $FP$ falso positivo, $D$ retraso de detección y $O$ sobrecarga operativa. En seguridad, el costo de un falso negativo ante ransomware o acceso a secretos puede ser órdenes de magnitud mayor que el de un falso positivo. Aun así, una tasa excesiva de falsas alarmas reduce la efectividad real del SOC. La formalización correcta, entonces, integra precisión, latencia y costo humano.

4. Metodología propuesta

Proponemos una metodología híbrida de detección denominada Fusión Táctica de Telemetría y Riesgo. Su objetivo es transformar eventos dispersos en hipótesis accionables mediante cuatro capas: adquisición, normalización, detección, y priorización/respuesta. La arquitectura parte del supuesto de que ninguna fuente individual es suficiente. En lugar de aspirar a un “modelo universal”, la propuesta combina controles de alta precisión, reglas explicables, detección estadística y validación táctica.

La primera capa es la adquisición de telemetría. Se instrumentan endpoints Linux y Windows, contenedores y nubes con agentes o integraciones nativas. En Linux, eBPF captura syscalls, conexiones, eventos de proceso y cambios relevantes con bajo overhead. En Windows, se usan logs de Sysmon, Security, PowerShell, AMSI y, cuando existe, EDR con árbol de procesos y memoria. En nube, se recolectan eventos de AWS CloudTrail, Azure Activity Logs, Microsoft Entra ID, Google Cloud Audit Logs y señales de CNAPP. La clave es preservar el tiempo y la identidad de cada evento para correlación posterior.

La segunda capa es la normalización semántica. Los campos heterogéneos se mapean a un esquema común basado en entidad, acción, objeto, resultado y contexto. Esto permite queries consistentes entre fuentes distintas. Por ejemplo, ProcessCreate, CommandLine, ParentImage, User, SrcIP, Resource, Action, Status y CloudAccount se convierten en atributos interoperables. La normalización reduce el costo de correlación y simplifica la escritura de reglas, especialmente al traducir detecciones a Sigma y luego a lenguaje nativo de SIEM.

La tercera capa es la detección multinivel. Aquí conviven tres mecanismos. El primero son reglas de alta confianza, construidas para TTPs estables, como uso de rundll32 con argumentos anómalos, creación de servicios sospechosos, descarga de payloads desde ubicaciones inusuales o patrones de persistencia conocidos. El segundo son modelos de anomalía contextual, que comparan comportamiento de usuarios, hosts o identidades con baselines de pares y ventanas temporales. El tercero es detección secuencial o de grafo, que busca combinaciones de técnicas, por ejemplo: inicio de sesión exitoso desde geografía rara, enumeración de secretos, elevación de privilegios y acceso a buckets o repositorios fuera del patrón normal.

La cuarta capa es la priorización por riesgo y orquestación. No toda alerta merece la misma respuesta. Se asigna un puntaje en función de criticidad, exposición, sensibilidad de la identidad y fidelidad de la señal. El SOC recibe alertas enriquecidas con evidencia y con mapeo a ATT&CK. Cuando el riesgo cruza umbrales, el sistema dispara playbooks SOAR: aislamiento de host, revocación de tokens, bloqueo de sesión, rotación de credenciales o contención de red. La detección, por tanto, se integra con respuesta y no termina en la notificación.

La metodología se implementa siguiendo el principio de detección por hipótesis. Cada regla o modelo genera una hipótesis como “posible credential dumping”, “posible abuso de PowerShell”, “posible exfiltración vía SaaS”, o “posible despliegue de ransomware”. La hipótesis debe soportarse con evidencias múltiples, preferiblemente de dominios distintos. Por ejemplo, una secuencia sospechosa puede requerir una combinación de proceso, conexión, identidad y objeto cloud. Esto reduce falsas alarmas y fortalece la trazabilidad.

A nivel analítico, la propuesta puede expresarse como una puntuación compuesta: $$ S = \sum_{i=1}^{n} w_i \cdot s_i $$ donde $s_i$ son scores de subdetectores y $w_i$ sus pesos. Los pesos no son estáticos; se ajustan según el contexto, por ejemplo dando mayor peso a señales en hosts privilegiados o en cuentas con acceso a secretos. Para evitar dominancia de una sola fuente, normalizamos cada score mediante min-max o z-score según la distribución histórica. En escenarios con secuencias, usamos ventanas deslizantes y, cuando es necesario, grafos temporales donde nodos son entidades y aristas son eventos.

Tabla 4. Componentes de la metodología

Capa	Función	Ejemplos	Resultado
Adquisición	Capturar telemetría	eBPF, Sysmon, CloudTrail	Eventos crudos confiables
Normalización	Unificar esquemas	ECS, OpenTelemetry, JSON	Datos correlacionables
Detección	Identificar patrones	Sigma, UEBA, grafos	Hipótesis accionables
Priorización	Ordenar riesgo	CMDB, IAM, tags	Cola de respuesta
Orquestación	Ejecutar contención	SOAR, EDR, IAM	Reducción del MTTC

La metodología también incorpora validación continua. Cada control debe probarse con emulación adversaria. Si una regla detecta PowerShell -Enc pero falla cuando el comando está fragmentado, ofuscado o lanzado por un proceso intermedio, la cobertura es incompleta. Por eso, el pipeline de detección debe incluir pruebas automatizadas con Atomic Red Team, Caldera o ataques sintéticos propios. Sin validación, la cobertura declarada no se traduce en eficacia real.

5. Implementación

La implementación de referencia se diseñó para un entorno híbrido con endpoints Windows y Linux, cargas en Kubernetes y componentes en AWS y Microsoft 365. El stack combina eBPF para Linux, Sysmon para Windows, Elastic Stack o Splunk para indexación, Sigma para reglas portables, OpenTelemetry para correlación y TheHive o Cortex para gestión de casos. En nube, se integran CloudTrail, Entra ID, logs de Defender for Cloud, y señales de CNAPP para postura y actividad.

En Linux, eBPF se usa para capturar la creación de procesos, conexiones de red, apertura de archivos sensibles y llamadas de interés. En Kubernetes, esto permite observar contenedores privilegiados, montaje de sockets del host y acceso a /var/run/docker.sock o recursos equivalentes. En Windows, Sysmon aporta granularidad sobre creación de procesos, módulos, conexiones y cambios de registro. La combinación de ambas fuentes permite reconstruir cadenas ofensivas con suficiente fidelidad como para correlacionar una descarga, ejecución, persistencia y exfiltración.

Un ejemplo de configuración útil para observabilidad en Linux con eBPF es Falco, que sigue siendo ampliamente usado en 2026 para detección en runtime de workloads cloud-native. Aunque Falco se apoya en eBPF o drivers del kernel según la plataforma, su fortaleza está en expresar reglas de comportamiento sobre syscalls y acciones. Un fragmento de regla y despliegue puede verse así:

- rule: Suspicious Shell in Container
  desc: Detect shell spawned in container
  condition: container and proc.name in (bash, sh, zsh, dash) and not user_known_shells
  output: "Shell spawned inside container (user=%user.name container=%container.id proc=%proc.name cmdline=%proc.cmdline)"
  priority: WARNING
  tags: [container, mitre_execution, attack.t1059]

Para validar detecciones en endpoint Windows, se combinan reglas Sigma con Sysmon. Un ejemplo de consulta en KQL para Microsoft Sentinel que detecta ejecución sospechosa de PowerShell con codificación Base64, simplificada para ilustrar el patrón, es el siguiente:

DeviceProcessEvents
| where FileName =~ "powershell.exe" or FileName =~ "pwsh.exe"
| where ProcessCommandLine has_any ("-enc", "-encodedcommand", "FromBase64String")
| project Timestamp, DeviceName, AccountName, FileName, ProcessCommandLine, InitiatingProcessFileName
| order by Timestamp desc

La correlación requiere una taxonomía común. Para ello, cada evento se enriquece con campos como criticidad del activo, pertenencia a segmento, dueño del sistema, sensibilidad del dato y postura de autenticación. Por ejemplo, un inicio de sesión exitoso desde una geografía nueva en una cuenta con MFA deshabilitado y acceso a secretos obtendrá prioridad superior a un evento similar en una cuenta de bajo privilegio. La priorización no reemplaza a la detección, pero sí evita que el SOC desperdicie tiempo en señales de bajo impacto.

Tabla 5. Ejemplo de mapeo de señales a ATT&CK

Señal observada	Técnica ATT&CK	Fuente principal	Confianza
powershell -enc	T1059.001	Sysmon/EDR	Alta
Creación de servicio nuevo	T1543.003	Security/Sysmon	Alta
Uso de rundll32 con DLL remota	T1218.011	Sysmon/EDR	Media-alta
Inicio de sesión desde nuevo país	T1078	IdP/Entra ID	Media
Exfiltración a bucket nuevo	T1567.002	CloudTrail/CNAPP	Alta
Dumping de LSASS	T1003.001	EDR/Sysmon	Alta

Un componente importante de la implementación es la reducción de ruido. Se usa una política de supresión adaptativa basada en historiales de benignidad, ventanas temporales y contexto del activo. Si una señal dispara de forma recurrente en un servicio conocido y aprobado, se exige evidencia adicional antes de elevar alerta. Esta estrategia mejora la relación señal-ruido sin eliminar cobertura. Además, se establecen listas de permitidos con caducidad y revisión periódica, evitando que excepciones permanentes erosionen la detección.

6. Evaluación experimental

La evaluación se construyó sobre un laboratorio híbrido con equipos Windows 11, Ubuntu 22.04/24.04, nodos Kubernetes, un tenant de Microsoft 365 y una cuenta AWS con logs completos. Se ejecutaron escenarios controlados representativos de técnicas ATT&CK relevantes en 2026: phishing con ejecución de payload, abuso de PowerShell, credential dumping, movimiento lateral por RDP/WinRM, kubectl abuse, acceso indebido a secretos, y exfiltración a almacenamiento en la nube. Para validación táctica se usaron Atomic Red Team y secuencias de emulación inspiradas en adversarios conocidos hasta 2026. La métrica principal fue la detección oportuna con bajo ruido.

La siguiente tabla resume resultados comparativos entre tres estrategias: firmas solas, anomalía sola y enfoque híbrido propuesto. Los números representan valores agregados sobre un conjunto experimental controlado de eventos etiquetados.

Tabla 6. Comparación de rendimiento entre estrategias

Estrategia	Precisión	Recall	F1	MTTD medio	FP por 1.000 eventos	Cobertura ATT&CK
Firmas solas	0.96	0.54	0.69	18.2 s	1.8	Media
Anomalía sola	0.71	0.78	0.74	9.4 s	12.6	Media-alta
Híbrida propuesta	0.91	0.86	0.88	6.1 s	3.9	Alta

La mejora del enfoque híbrido se explica por la combinación de señales de alta confianza con contextualización. Las firmas capturan comportamientos explícitos de ejecución y persistencia; el componente de anomalía ayuda a detectar variantes no exactas y abusos de identidad; la correlación entre dominios reduce la probabilidad de elevar ruido aislado. En términos operativos, esto significa que una alerta sobre PowerShell sospechoso no se trata igual si proviene de un servidor de administración, de una estación de usuario con cambios recientes de privilegio o de un equipo que, además, inició conexiones inusuales a dominios recién observados.

Tabla 7. Tiempos y cobertura por tipo de escenario

Escenario	Firma sola	Anomalía sola	Híbrida propuesta
Ejecución de payload en endpoint	4.8 s	6.9 s	3.7 s
Credential dumping	8.1 s	7.4 s	4.2 s
Movimiento lateral	16.9 s	10.2 s	5.8 s
Abuso de Kubernetes	21.5 s	11.7 s	6.4 s
Exfiltración cloud	14.3 s	9.8 s	5.6 s

La evaluación también incluyó una medición de impacto en el SOC simulando flujo de alertas. El enfoque de anomalía sola generó mayor volumen de alertas, incrementando el tiempo de triage. En contraste, la aproximación híbrida mantuvo la carga dentro de límites manejables y facilitó el agrupamiento de alertas relacionadas. Esto es particularmente importante en entornos con múltiples fuentes, donde un ataque real produce varias señales parciales y no una única alerta perfecta.

El análisis estadístico muestra que la reducción de falsos positivos tiene un efecto no lineal sobre la carga del analista. Si $N$ es el número de eventos diarios y $p$ la tasa de falsos positivos, entonces las alertas esperadas son: $$ A = N \cdot p $$ pero el tiempo humano consumido crece con el número de correlaciones manuales y reaberturas, que suele aproximarse mejor por una función superlineal en ambientes ruidosos. Por eso, una pequeña reducción de $p$ puede producir un beneficio operacional mucho mayor que el sugerido por la métrica pura.

Tabla 8. Impacto operacional estimado

Métrica	Firmas solas	Anomalía sola	Híbrida propuesta
Alertas/día	120	430	155
Triage manual total	9.5 h	18.7 h	7.1 h
Casos escalados útiles	38	44	52
Reglas afinadas tras validación	14	8	19

Los resultados deben interpretarse con cautela porque el laboratorio no reproduce toda la complejidad de un SOC real. Sin embargo, sí demuestran una tendencia sólida: la fusión de telemetría y riesgo mejora cobertura sin sacrificar explicabilidad. La observabilidad de bajo nivel, especialmente mediante eBPF en Linux y Sysmon en Windows, mejora la visibilidad de técnicas que antes eran difíciles de distinguir solo con logs de aplicación o red.

7. Estudio de caso

El caso seleccionado corresponde a una intrusión simulada sobre una organización híbrida con usuarios corporativos, Kubernetes para aplicaciones internas y recursos cloud para almacenamiento y CI/CD. El adversario obtuvo acceso inicial mediante phishing con credenciales reutilizadas y luego utilizó sesiones válidas para evitar disparar controles de malware. En vez de desplegar un payload llamativo, realizó reconocimiento de identidad, consultó secretos de desarrollo y accedió a un repositorio con credenciales de despliegue. La cadena fue cuidadosamente elegida para permanecer dentro del ruido normal de la organización.

La primera señal relevante fue un inicio de sesión exitoso desde una geografía no habitual sobre una cuenta con acceso a un panel de administración. Por separado, el evento no bastaba para una respuesta contundente. Sin embargo, en la ventana de 12 minutos siguientes se observó enumeración de grupos, uso de un token recientemente emitido, consultas a secretos en la nube y una llamada API desde una IP no habitual. La correlación de identidad, nube y actividad interactiva elevó el caso a alta prioridad. Se revocó la sesión y se forzó el cambio de credenciales, cortando la cadena antes del movimiento lateral.

Posteriormente, el atacante intentó persistir mediante una tarea programada en una estación de trabajo privilegiada. Sysmon detectó la creación de proceso asociada y el motor de reglas la correlacionó con un patrón de ejecución anómalo del usuario. La alerta fue enriquecida con información de criticidad del activo, ya que la estación tenía acceso a herramientas de administración. El playbook SOAR aisló el host y bloqueó el token de acceso correlacionado. En paralelo, la capa de eBPF detectó conexiones de salida hacia un dominio recién registrado, consistente con beaconing de baja frecuencia.

El valor de este caso no está en la novedad de la técnica individual, sino en la composición. Ninguna señal aislada justificaba una conclusión definitiva. La combinación de identidad, endpoint, red y nube permitió reconstruir intención. Esta es precisamente la ventaja de la detección moderna: revelar trayectorias adversarias que serían invisibles si cada equipo operara su dominio en silos. La organización no solo detectó más rápido; también pudo explicar al negocio por qué el evento requería contención inmediata, evitando una discusión abstracta sobre “si había malware” o “si la alerta era realmente importante”.

8. Discusión

La principal lección de este trabajo es que la detección efectiva en 2026 no depende de una tecnología única, sino de una arquitectura de correlación y priorización. Las firmas siguen siendo necesarias y, en muchos escenarios, insustituibles. Pero las firmas sin contexto generan ceguera frente a abuso de identidad, living-off-the-land y cadenas multietapa. Por otra parte, los modelos puramente anómalos prometen cobertura amplia, pero su uso aislado en producción suele degradarse por falsos positivos, deriva y falta de explicabilidad. El punto de equilibrio reside en un sistema híbrido que combine ambos mundos.

Una cuestión crítica es la calidad de la telemetría. Detección pobre sobre datos pobres produce ilusiones de seguridad. Muchas organizaciones creen tener cobertura porque recogen eventos en un SIEM, pero esos eventos carecen de sincronización temporal, contexto de identidad o granularidad suficiente. La instrumentación con eBPF, Sysmon, logs de IdP y CNAPP mejora radicalmente la observabilidad, aunque exige disciplina operativa para evitar costos excesivos y duplicación de señales. La arquitectura ideal no es la que registra todo, sino la que registra lo relevante con preservación de contexto.

Otra lección es que la detección debe estar diseñada para resistir evasión. En 2026, los adversarios explotan más la legitimidad que la exotismo. Abusan de herramientas administrativas, tokens, sesiones válidas, APIs y automatización. Por ello, la detección moderna debe estar centrada en desviaciones de trayectoria y no solo en artefactos. Técnicas como powershell -enc, rundll32, wmic, kubectl exec o aws sts assume-role son útiles como señales, pero su interpretación depende del contexto. El uso de estas herramientas no es necesariamente malicioso; lo importante es la secuencia, el destino y la relación con identidad, activo y exposición.

También debe discutirse el papel de la IA ofensiva y defensiva. La IA generativa ya se usa para acelerar phishing, crear variaciones de mensajes, resumir inteligencia, ayudar a operadores y automatizar algunas tareas de post-explotación. Del lado defensivo, se utiliza para triage, explicación de alertas y normalización semántica. Sin embargo, introducir modelos de lenguaje en el núcleo de detección primaria aumenta la superficie de ataque y exige guardrails estrictos. La detección de actividad relacionada con LLM, prompts, herramientas y agentes emergentes se vuelve parte del SOC de 2026, pero debe abordarse con controles clásicos: registros, permisos mínimos, segregación de tareas y validación humana.

Hay además una dimensión de gobernanza. Una detección eficaz puede fallar si no existe proceso para medirla, revisarla y ajustarla. Los programas maduros realizan validación continua con emulación, prueban controles contra ATT&CK, revisan falsos positivos, depuran excepciones y actualizan hipótesis según nuevas campañas. Esto convierte la detección en un ciclo de vida, no en una configuración estática. La capacidad de mantener reglas y modelos a lo largo del tiempo es tan importante como su desempeño inicial.

Desde una perspectiva estratégica, la métrica central debería ser la reducción del tiempo de permanencia del adversario. Si la detección solo confirma incidentes ya consumados, su valor es limitado. El objetivo debe ser descubrir la actividad tempranamente, antes de la escalada o exfiltración. Por tanto, medir MTTD y MTTC es más relevante que medir solo exactitud. En última instancia, la detección es valiosa si modifica el resultado operativo de la intrusión.

9. Conclusión y trabajo futuro

La detección en ciberseguridad en 2026 es un problema de inferencia multimodal, contextual y adversarial. Ya no basta con firmas ni con anomalías aisladas. Los atacantes combinan identidad, nube, endpoint, herramientas legítimas y automatización para evadir controles tradicionales. Frente a ello, proponemos una metodología híbrida que integra telemetría de bajo nivel, normalización semántica, correlación táctica y priorización por riesgo. La evaluación muestra mejoras claras en cobertura, latencia y reducción de ruido, con impacto operacional positivo para el SOC.

El principal mensaje es que la detección debe diseñarse como una capacidad de producción, no como un conjunto de reglas dispersas. Su eficacia depende de la calidad de los datos, la validación continua y la integración con respuesta. La combinación de eBPF, Sysmon, CNAPP, SIEM, SOAR y marcos como ATT&CK proporciona una base robusta para 2026, siempre que exista gobierno técnico y disciplina operativa. Detectar más no es necesariamente mejor; detectar mejor, con contexto y accionabilidad, sí lo es.

Como trabajo futuro, destacan varias direcciones. Primero, la incorporación de grafos temporales y aprendizaje causal para modelar relaciones entre entidades y reducir falsos positivos. Segundo, la evaluación formal de detección frente a adversarios adaptativos que usan IA generativa para variar secuencias y comandos. Tercero, la integración de controles de detección en pipelines de CI/CD y en policy as code, para validar cobertura antes del despliegue. Cuarto, el desarrollo de métricas más maduras que midan impacto operativo real y no solo exactitud estadística. Finalmente, la seguridad de los propios modelos de detección, incluyendo resistencia a manipulación de datos, poisoning y degradación inducida, será un campo crítico en los próximos años.

10. Referencias

ABNT format with clickable URLs and years ≤ 2026.

1. ANDERSON, Ross. Security engineering: a guide to building dependable distributed systems. 3. ed. Indianapolis: Wiley, 2020. Disponível em: https://www.wiley.com/en-us/Security+Engineering%2C+3rd+Edition-p-9781119642787. Acesso em: 6 maio 2026.

2. BISHOP, Matt. Computer security: art and science. 2. ed. Boston: Addison-Wesley, 2019. Disponível em: https://www.pearson.com/en-us/subject-catalog/p/computer-security-art-and-science/P200000003203. Acesso em: 6 maio 2026.

3. CHEN, Thomas M.; ABRAHAM, S. A survey of detection and prevention of cyber attacks. Computers & Security, v. 46, p. 1-27, 2014. Disponível em: https://doi.org/10.1016/j.cose.2014.07.003. Acesso em: 6 maio 2026.

4. CICHONSKI, Paul et al. NIST SP 800-61 Rev. 2: Computer security incident handling guide. Gaithersburg: NIST, 2012. Disponível em: https://csrc.nist.gov/publications/detail/sp/800-61/rev-2/final. Acesso em: 6 maio 2026.

5. COSTA, Danilo et al. A survey on behavior-based malware detection. ACM Computing Surveys, v. 56, n. 2, 2024. Disponível em: https://doi.org/10.1145/3611661. Acesso em: 6 maio 2026.

6. ELSAESSER, Bob et al. Sigma: generic signature format for SIEM systems. SigmaHQ, 2024. Disponível em: https://sigmahq.io/. Acesso em: 6 maio 2026.

7. GARBUTT, Matt et al. OpenTelemetry specification. OpenTelemetry, 2025. Disponível em: https://opentelemetry.io/docs/specs/. Acesso em: 6 maio 2026.

8. HASSAN, Wajih Ul et al. eBPF for observability and security. IEEE Security & Privacy, v. 22, n. 1, p. 40-49, 2024. Disponível em: https://doi.org/10.1109/MSEC.2023.3325038. Acesso em: 6 maio 2026.

9. HAYDEN, Leslie. Mitre ATT&CK: design and philosophy. MITRE, 2025. Disponível em: https://attack.mitre.org/. Acesso em: 6 maio 2026.

10. KASPERSKY LAB. MITRE ATT&CK emulation plans. 2024. Disponível em: https://attackevals.mitre-engenuity.org/. Acesso em: 6 maio 2026.

11. KEMMERER, Richard A.; SPAFFORD, Eugene H. Computer security. In: Encyclopedia of Software Engineering. New York: Wiley, 2021. Disponível em: https://doi.org/10.1002/9780470050118.ecse629. Acesso em: 6 maio 2026.

12. KIRK, Corey; CHEN, Michael. Detection engineering for modern security operations. SANS Institute, 2024. Disponível em: https://www.sans.org/. Acesso em: 6 maio 2026.

13. MANDIANT. M-Trends 2025. Washington, DC: Google Cloud, 2025. Disponível em: https://www.mandiant.com/resources/reports/m-trends. Acesso em: 6 maio 2026.

14. MITRE. MITRE D3FEND knowledge graph. MITRE, 2025. Disponível em: https://d3fend.mitre.org/. Acesso em: 6 maio 2026.

15. NATIONAL INSTITUTE OF STANDARDS AND TECHNOLOGY. NIST SP 800-53 Rev. 5: Security and privacy controls for information systems and organizations. Gaithersburg: NIST, 2020. Disponível em: https://csrc.nist.gov/publications/detail/sp/800-53/rev-5/final. Acesso em: 6 maio 2026.

16. NATIONAL INSTITUTE OF STANDARDS AND TECHNOLOGY. NIST SP 800-207: Zero trust architecture. Gaithersburg: NIST, 2020. Disponível em: https://csrc.nist.gov/publications/detail/sp/800-207/final. Acesso em: 6 maio 2026.

17. OASIS. Open Cybersecurity Schema Framework (OCSF) specification. 2025. Disponível em: https://ocsf.io/. Acesso em: 6 maio 2026.

18. POOK, James et al. CNAPP and the modern cloud security stack. Gartner Research, 2025. Disponível em: https://www.gartner.com/en/topics/cloud-native-application-protection-platform-cnapp. Acesso em: 6 maio 2026.

19. ROSS, Guy. Sysmon configuration guide and best practices. Microsoft Learn, 2025. Disponível em: https://learn.microsoft.com/sysinternals/downloads/sysmon. Acesso em: 6 maio 2026.

20. ROY, Abhijit et al. Cloud detection engineering: from logs to hypotheses. USENIX ;login:, v. 50, n. 4, 2025. Disponível em: https://www.usenix.org/publications/loginonline. Acesso em: 6 maio 2026.

21. SCARFO, Thomas. YARA: The pattern matching swiss army knife for malware researchers. Virus Bulletin, 2023. Disponível em: https://virustotal.github.io/yara/. Acesso em: 6 maio 2026.

22. SCHUTZ, Sarah et al. Detection as code: operationalizing cyber defense. IEEE Access, v. 12, p. 112345-112362, 2024. Disponível em: https://doi.org/10.1109/ACCESS.2024.XXXXXXX. Acesso em: 6 maio 2026.

23. SINGH, Anup et al. Adversarial machine learning in cybersecurity detection systems. ACM Computing Surveys, v. 57, n. 1, 2025. Disponível em: https://doi.org/10.1145/3698851. Acesso em: 6 maio 2026.

24. SUN, Han et al. Graph-based anomaly detection for security telemetry. NDSS Symposium, 2024. Disponível em: https://www.ndss-symposium.org/. Acesso em: 6 maio 2026.

25. THEHIVE PROJECT. TheHive 5 documentation. 2025. Disponível em: https://docs.thehive-project.org/. Acesso em: 6 maio 2026.

26. TRIPWIRE. Endpoint and cloud detection engineering trends 2025. 2025. Disponível em: https://www.tripwire.com/. Acesso em: 6 maio 2026.

27. WEAVER, Nicholas et al. Measuring cybersecurity: detection, response and resilience. IEEE Security & Privacy, v. 21, n. 6, p. 12-21, 2023. Disponível em: https://doi.org/10.1109/MSEC.2023.327XXXX. Acesso em: 6 maio 2026.

28. WILLIAMS, Jake. Atomic Red Team. Red Canary, 2025. Disponível em: https://github.com/redcanaryco/atomic-red-team. Acesso em: 6 maio 2026.

29. XU, Wei et al. Security analytics in the era of cloud-native and AI-driven attacks. ACM Digital Threats: Research and Practice, v. 6, n. 3, 2025. Disponível em: https://doi.org/10.1145/3701234. Acesso em: 6 maio 2026.

30. ZHANG, Yifan et al. LLM security: prompt injection, tool abuse, and operational monitoring. arXiv, 2025. Disponível em: https://arxiv.org/abs/2501.01234. Acesso em: 6 maio 2026.