Detección de Amenazas en Ciberseguridad en 2026: Arquitectura Híbrida de Señales, eBPF, Telemetría de Identidad e Inferencia Asistida por Aprendizaje Automático para Entornos Cloud-Native y SaaS

1. Introducción

La detección de amenazas en ciberseguridad dejó de ser un problema de inspección perimetral hace más de una década. En 2026, esta disciplina se ha convertido en una función sociotécnica de gran complejidad, donde la tarea no consiste solo en identificar malware o tráfico sospechoso, sino en reconstruir intenciones adversarias a partir de señales heterogéneas, incompletas y a menudo contradictorias. La consolidación de entornos cloud-native, la externalización de procesos críticos a SaaS, la autenticación federada, la adopción de zero trust y la automatización de despliegues han desplazado el centro de gravedad de la detección desde el paquete y el binario hacia la identidad, la sesión y la secuencia de acciones. Al mismo tiempo, la expansión de la inteligencia artificial generativa ha amplificado tanto la velocidad de las campañas ofensivas como la sofisticación de la evasión, la ingeniería social y el abuso de contenido sintético (MITRE, 2024; CISA, 2024).

En términos operativos, la “detección” ya no puede definirse como la mera coincidencia con una firma. Un adversario contemporáneo puede usar herramientas legítimas del sistema, automatización en la nube, cuentas válidas, integraciones OAuth, acceso vía API y técnicas living-off-the-land para permanecer por debajo de umbrales estáticos. En paralelo, los equipos defensivos sufren una inflación de telemetría: logs de endpoints, flujos de red, eventos de identidad, auditorías de nube, trazas de aplicación, métricas de seguridad de contenedores y registros de proveedores SaaS. La abundancia de datos no se traduce automáticamente en visibilidad; de hecho, puede ocultar los patrones relevantes si no existe una capa de correlación y priorización. Por ello, la detección efectiva en 2026 debe ser contextual, secuencial, sensible a identidad y gobernada por restricciones de latencia y costo.

La experiencia reciente muestra que las intrusiones más dañinas combinan múltiples dominios. Un correo de phishing puede derivar en robo de tokens, luego en acceso a un IdP, después en creación de persistencia mediante aplicaciones OAuth o reglas de reenvío, y finalmente en exfiltración desde un repositorio SaaS sin tocar el endpoint tradicional. Esta cadena no se captura con un solo sensor. Requiere observabilidad distribuida, normalización de eventos, correlación temporal y semántica, así como modelos que sean robustos frente a variaciones en el comportamiento legítimo. La contribución de eBPF al monitoreo de Linux, la madurez de Sigma como lenguaje de detección portátil, la consolidación de KQL en entornos Microsoft, y el uso de estándares como OpenTelemetry han facilitado la instrumentación, pero no resuelven por sí solos el problema central: decidir qué constituye una desviación significativa en un mar de actividad normal (SIGMA HQ, 2024; OPEN TELEMETRY, 2024).

Este artículo aborda la detección como un problema de ingeniería defensiva y de ciencia aplicada. La hipótesis principal es que la mejor defensa en 2026 surge de un enfoque híbrido: reglas de alto valor para TTPs bien comprendidas, análisis estadístico y de secuencias para anomalías sutiles, y enriquecimiento contextual con inteligencia de amenazas, postura de identidad y superficie cloud. La propuesta integra telemetría de host basada en eBPF, auditd y Sysmon; telemetría de red mediante Zeek y Suricata; telemetría de identidad desde Okta, Entra ID, Google Workspace y proveedores IAM; y telemetría de nube desde AWS CloudTrail, Azure Activity Logs y registros de Kubernetes. A partir de esa base, se define una capa de normalización y detección multi-señal capaz de operar con baja latencia y de emitir alertas accionables para analistas humanos.

Desde la perspectiva académica, la detección ha sido estudiada en múltiples paradigmas: firmas, anomalía, comportamiento, aprendizaje automático y grafos. Sin embargo, existe una brecha entre la literatura y la operación real en entornos híbridos. Muchos trabajos asumen dataset limpios, ataques aislados o un único dominio de telemetría. En producción, los atacantes mezclan técnicas, los sensores fallan, los logs son incompletos y las ventanas temporales están sujetas a desfases. La formalización del problema debe, por tanto, reconocer el carácter adversarial y económico de la detección: cada decisión de diseño implica un trade-off entre cobertura, precisión, latencia, costo de almacenamiento y carga analítica. Si $\mathcal{S}$ es el conjunto de señales, $\mathcal{A}$ el conjunto de acciones adversarias y $C$ el costo operacional, el objetivo no es maximizar una métrica aislada sino optimizar una función multiobjetivo del tipo $J = \alpha R + \beta P - \gamma C - \delta L$, donde $R$ es el recall, $P$ la precisión y $L$ la latencia.

El contexto de 2026 añade además una dimensión de gobernanza. Los marcos de Zero Trust Architecture, la adopción de CNAPP, la presión regulatoria sobre privacidad y la aparición de controles para IA y modelos de lenguaje obligan a que los sistemas de detección sean explicables, auditables y minimicen exposición de datos. La detección moderna debe coexistir con restricciones de retención, soberanía de datos y controles de acceso basados en necesidad de conocer. Esto es especialmente importante cuando los sensores capturan contenido potencialmente sensible, como consultas, payloads o comunicaciones internas. La arquitectura propuesta en este trabajo incorpora diseño por capas, minimización de datos, tokenización de identificadores y políticas de retención diferenciadas.

2. Background and Related Work

La literatura de detección en ciberseguridad puede organizarse en cuatro grandes etapas. La primera corresponde a la era de firmas y reglas perimetrales, donde IDS/IPS como Snort y Suricata, junto con antivirus tradicionales, dominaban la primera línea defensiva. El valor de este enfoque radica en su alta precisión para amenazas conocidas, pero su limitación es estructural: la firma solo captura lo ya observado. La segunda etapa incorporó detección basada en anomalías y estadística, motivada por la necesidad de identificar comportamientos no vistos previamente, especialmente en tráfico de red y uso de recursos. La tercera etapa introdujo el aprendizaje automático supervisado y no supervisado, con métodos como árboles de decisión, random forests, SVM, clustering y autoencoders, aplicados a flujos, procesos y autenticación. La cuarta etapa, vigente en 2026, combina todas las anteriores con telemetría rica, correlación entre dominios y modelos de secuencia que intentan reconstruir cadenas de ataque (Sommer y Paxson, 2010; Buczak y Guven, 2016).

Una parte importante de la evolución reciente proviene de la observabilidad del sistema operativo. Sysmon, auditd y, más recientemente, eBPF han permitido instrumentar eventos de proceso, red, archivo y syscall con gran granularidad. eBPF, en particular, ha transformado la defensa en Linux al ofrecer observación de baja sobrecarga y alta flexibilidad, lo que ha sido aprovechado por plataformas de seguridad y detección en runtime para contenedores y hosts cloud-native. Este cambio es relevante porque gran parte de la actividad adversaria moderna se ejecuta dentro del propio sistema operativo o mediante software legítimo ya presente en el entorno. La telemetría de procesos y syscalls ofrece una mejor superficie de observación que la red sola, aunque exige cuidado para evitar sesgos y falsos positivos por actividad administrativa normal (Holloway, 2023; Cilium, 2024).

En paralelo, la detección en la nube ha ganado centralidad. CloudTrail, Azure Activity Logs, Entra ID Sign-in logs, Google Cloud Audit Logs y los registros de controladores Kubernetes ofrecen visibilidad sobre acciones administrativas, cambios de configuración, creación de credenciales y acceso a recursos. El problema es que el volumen y la heterogeneidad de estos eventos obligan a sistemas de normalización y correlación. CNAPP y CSPM ayudan a detectar errores de configuración y exposición, pero no sustituyen la detección de comportamiento adversario en tiempo de ejecución. La literatura y la práctica muestran que gran parte de los incidentes cloud modernos se apoyan en abuso de identidad, permisos excesivos, claves expuestas o tokens de sesión, más que en explotación clásica de vulnerabilidades remotas (NIST, 2020; Microsoft, 2024).

La detección basada en identidad se ha vuelto crítica en la era de zero trust. Los atacantes buscan autenticaciones válidas, elevación de privilegios, consentimiento OAuth, secuestro de sesiones y abuso de dispositivos confiables. Los logs de autenticación no solo registran éxito o fallo, sino también geolocalización, postura del dispositivo, tipo de cliente, riesgo y patrones temporales. La correlación de eventos de identidad permite construir secuencias que distinguen viajes imposibles, acceso desde nuevos ASN, uso inusual de tokens y cambios de política. Esta orientación hacia identidad responde a la realidad de que el perímetro ha desaparecido y de que la sesión se ha convertido en la unidad de control más valiosa (Gartner, 2024; CISA, 2023).

En detección basada en reglas, Sigma se ha consolidado como un lenguaje portátil para describir patrones de interés en múltiples backends, mientras que YARA sigue siendo útil en análisis de archivos y memoria. Sigma no sustituye la lógica nativa de cada SIEM, pero reduce la fragmentación y mejora la colaboración entre equipos. KQL, por su parte, ofrece gran expresividad para entornos Microsoft, especialmente en Microsoft Sentinel y Defender. Aun así, el uso eficaz de reglas requiere ingeniería: selección de eventos, exclusiones, ventanas temporales y umbrales adaptados al contexto. La evidencia operativa demuestra que reglas demasiado generales generan fatiga de alertas, mientras que reglas excesivamente específicas dejan escapar variantes del mismo TTP (SIGMA HQ, 2024; Microsoft, 2024).

En aprendizaje automático, los resultados son mixtos. Muchos modelos reportan mejoras en datasets controlados, pero el entorno real introduce drift, desbalance extremo, etiquetas ruidosas y cambios continuos en la infraestructura. El problema de la detección adversaria no es un benchmark estático. Un modelo entrenado hoy puede degradarse rápidamente mañana por cambios en software, red, patrones de uso o por adaptación adversaria. Por ello, la investigación más útil en 2026 combina modelos con explicabilidad, retroalimentación humana y mecanismos de actualización. En particular, los modelos secuenciales y de grafos han mostrado mayor utilidad que las aproximaciones puramente tabulares para captar cadenas de eventos, aunque a costa de mayor complejidad operacional (Mirsky et al., 2018; Vinayakumar et al., 2020).

La industria ha convergido hacia arquitecturas de detección compuestas. Un ejemplo típico incluye sensores de endpoint, un SIEM, un data lake, un motor de correlación, enriquecimiento con threat intelligence y un SOAR para respuesta. Sin embargo, la sofisticación de esta pila no garantiza eficacia. El desafío es que cada capa introduce latencia, costo y potencial pérdida de fidelidad. La pregunta relevante no es si se puede recolectar más, sino si se puede detectar mejor. El éxito depende de una adecuada taxonomía de eventos, de una correlación temporal robusta y de una priorización basada en riesgo. En 2026, la mejor práctica ya no es “alertar todo”, sino “detectar lo accionable” con suficiente evidencia para guiar una respuesta rápida.

3. Threat Model and Problem Formalization

El modelo de amenaza considerado en este trabajo asume un adversario con acceso a capacidades realistas de 2026: phishing asistido por IA, robo de credenciales, abuso de tokens OAuth, uso de herramientas legítimas de administración, técnicas living-off-the-land, explotación de vulnerabilidades conocidas y persistencia en plataformas SaaS y cloud. No se asume un actor omnipotente, pero sí uno capaz de adaptar su TTP a las defensas visibles. También se asume que el adversario puede operar en múltiples dominios, desde endpoint y red hasta identidad y control plane en nube. Este supuesto refleja incidentes observados en la práctica y alineados con tácticas de MITRE ATT&CK para Enterprise, Cloud y Mobile (MITRE, 2024).

La superficie de detección se modela como un conjunto de fuentes $\mathcal{S} = {s_1, s_2, \dots, s_n}$, donde cada fuente emite eventos $e \in E$ con atributos temporales, espaciales y semánticos. Cada evento puede representarse como una tupla $e = \langle t, d, a, c, m \rangle$, donde $t$ es el tiempo, $d$ el dominio, $a$ la acción observada, $c$ el contexto y $m$ la metainformación. Una cadena de ataque es una secuencia parcial ordenada $\pi = (e_1, e_2, \dots, e_k)$ con dependencia causal aproximada. La detección consiste en asignar una puntuación de riesgo $r(\pi)$ y determinar si $\pi$ pertenece a una clase maliciosa o a una secuencia benigna. El problema es adversarial porque el atacante puede modular observables para reducir la puntuación sin necesariamente cambiar el objetivo.

La formalización operacional debe capturar tres restricciones. Primero, la restricción de latencia: la detección es útil solo si ocurre dentro de una ventana compatible con contención y respuesta. Si $T_d$ es el tiempo de detección y $T_c$ el tiempo de compromiso completo, se requiere $T_d \ll T_c$ para incidentes de alta criticidad. Segundo, la restricción de costo: no toda señal puede almacenarse ni procesarse a máxima resolución indefinidamente. Tercero, la restricción de error: una tasa excesiva de falsos positivos colapsa la capacidad del SOC. Por ello, la función objetivo debe optimizar varias dimensiones simultáneamente, por ejemplo:

$$ J = \lambda_1 \cdot \text{Recall} + \lambda_2 \cdot \text{Precision} + \lambda_3 \cdot \text{EarlyDetection} - \lambda_4 \cdot \text{Latency} - \lambda_5 \cdot \text{Cost} $$

donde $\lambda_i \ge 0$ y $\sum \lambda_i = 1$. En entornos reales, los pesos dependen del perfil de riesgo, del tipo de activo y de la madurez operativa. Un banco con tolerancia baja a fraude priorizará precisión y tiempo de detección, mientras que una organización de investigación priorizará cobertura y trazabilidad forense.

La hipótesis de trabajo es que la detección mejora sustancialmente cuando se combina una capa de reglas semánticas con una capa de puntuación contextual. Las reglas capturan eventos de alto valor: creación de cuentas privilegiadas, modificación de políticas, ejecución de herramientas conocidas, carga lateral sospechosa, acceso anómalo a secretos, cambios de configuración de MFA y consent grants inusuales. La puntuación contextual, en cambio, integra el historial del activo, la identidad, la geolocalización, la hora, el comportamiento previo y el linaje de procesos. Esta combinación reduce el problema clásico de la detección de anomalías puras, donde todo evento raro se considera sospechoso, incluso cuando es legítimo.

La formulación también incluye una noción de cobertura TTP. Sea $\mathcal{T}$ el conjunto de técnicas ATT&CK relevantes y sea $\mathcal{D}$ el conjunto de mecanismos de detección desplegados. Definimos la cobertura como:

$$ \text{Cobertura}(\mathcal{D}) = \frac{|{t \in \mathcal{T}: \exists d \in \mathcal{D} \text{ que detecta } t}|}{|\mathcal{T}|} $$

Sin embargo, no toda cobertura es equivalente. Una técnica detectada solo después de la exfiltración es menos valiosa que una detectada al inicio de la cadena. Por ello, proponemos distinguir cobertura temprana, intermedia y tardía, ponderadas por la posición en la secuencia de ataque. Esta distinción es especialmente relevante en campañas cloud e identidad, donde la persistencia puede no dejar artefactos tradicionales en disco o memoria.

4. Proposed Methodology

La metodología propuesta se apoya en una arquitectura de cuatro capas: ingestión, normalización, correlación y decisión. La capa de ingestión recolecta eventos desde endpoints, red, identidad y nube. La capa de normalización convierte eventos heterogéneos en un esquema común enriquecido con contexto mínimo necesario. La capa de correlación construye secuencias y subgrafos temporales. La capa de decisión aplica reglas deterministas, detección estadística y ranking de riesgo. El objetivo es lograr detección operacional sin requerir un laboratorio aislado ni supuestos irreales de datasets cerrados.

La primera capa utiliza fuentes concretas. En Linux, eBPF captura eventos de proceso, conexión, syscall y carga de módulos con overhead reducido. auditd complementa con auditoría de acciones sensibles, mientras que Zeek y Suricata proporcionan contexto de red y detección por protocolo. En Microsoft, Sysmon y Defender for Endpoint aportan telemetría de endpoint, y KQL facilita consultas correlativas. En cloud, CloudTrail, Entra ID, Okta, Google Workspace y auditorías de Kubernetes registran control plane e identidad. En SaaS, eventos de acceso, compartición, consentimiento y actividad administrativa completan el panorama. La propuesta no exige una herramienta única; exige una ontología mínima común y una estrategia de correlación coherente.

La segunda capa normaliza eventos en un esquema canónico con campos obligatorios: timestamp, asset_id, identity_id, source, action, object, result, confidence, severity, tags, att&ck_tactic y att&ck_technique. La normalización reduce el costo de integrar múltiples proveedores y permite que las reglas sean portables. También facilita la deduplicación, la supresión de ruido y la comparación entre dominios. Para enriquecer los eventos, se agrega información de reputación IP, ASN, geolocalización, riesgo de identidad, criticidad del activo, exposición a Internet y sensibilidad de los datos.

La tercera capa implementa correlación temporal y semántica. Temporalmente, se utilizan ventanas deslizantes y agrupación por sesión o entidad. Semánticamente, se asocian eventos que comparten identidad, host, proceso padre, token, app OAuth, bucket, namespace o repositorio. La correlación se puede representar como un grafo dirigido $G=(V,E)$ donde cada vértice es un evento o entidad y cada arista expresa dependencia, precedencia o relación. Sobre ese grafo se calculan features como centralidad, densidad local, secuencias frecuentes y transiciones raras. Este enfoque ayuda a detectar cadenas multi-etapa que no disparan reglas aisladas.

La cuarta capa produce decisiones. Se combinan tres familias de detectores. La primera son reglas de alta confianza, implementadas en Sigma, KQL, YARA y consultas nativas del SIEM. La segunda son modelos de anomalía, como Isolation Forest o autoencoders, entrenados sobre comportamiento legítimo por tipo de activo o identidad. La tercera son clasificadores o rankers de secuencia, que estiman la probabilidad de que un patrón observado corresponda a una cadena adversaria conocida. El score final puede modelarse como:

$$ S = w_r R + w_a A + w_s S_q + w_c Ctx $$

donde $R$ es la puntuación por reglas, $A$ la anomalía, $S_q$ la similitud secuencial y $Ctx$ el contexto enriquecido. Los pesos $w_i$ se ajustan por entorno y por tolerancia al riesgo. En producción, el score se calibra para que el umbral $ \tau $ minimice una pérdida esperada:

$$ \mathcal{L}(\tau) = c_{fp}\cdot FP(\tau) + c_{fn}\cdot FN(\tau) + c_d \cdot Delay(\tau) $$

La salida del sistema no es solo una alerta, sino un objeto accionable. Debe incluir evidencia, línea temporal, entidades implicadas, TTPs asociadas, nivel de confianza y recomendaciones de triage. La utilidad real de la detección depende de la calidad del contexto y de la reducción de ambigüedad para el analista. Por ello, la metodología incluye también un módulo de explicación que traduce eventos técnicos en narrativas operativas: “token OAuth nuevo desde ASN no habitual seguido de acceso a recurso sensible y exportación de datos”.

Tabla 1. Fuentes de telemetría y valor defensivo

Fuente	Ejemplos de eventos	Ventajas	Limitaciones
eBPF	syscalls, exec, connect, open, load_module	Baja sobrecarga, gran granularidad	Requiere hardening y experiencia Linux
Sysmon	process create, network connect, image load	Amplia adopción en Windows	Ruido si no se configura bien
Zeek	DNS, HTTP, TLS, SMB, SSH	Contexto rico de red	No ve contenido cifrado completo
Suricata	firmas, protocolos, app-layer	Detección de exploits conocidos	Sensible a evasión y cifrado
CloudTrail / Activity Logs	cambios de control plane, IAM, storage	Clave para cloud	Volumen alto, normalización compleja
Logs de identidad	MFA, sesiones, tokens, risk events	Detección de abuso de credenciales	Dependencia del proveedor
SaaS audit logs	compartir, consent, admin actions	Vital para persistencia SaaS	Cobertura desigual entre productos

Código 1. Ejemplo de regla Sigma para abuso de rundll32 con parámetros sospechosos

id: 8c7f0f13-5d2f-4b8e-b6f2-5a4f2d9f4c11
status: test
logsource:
  product: windows
  category: process_creation
detection:
  selection:
    Image|endswith: '\rundll32.exe'
    CommandLine|contains:
      - 'javascript:'
      - 'ShellExec_RunDLL'
      - '.cpl'
      - 'url.dll,FileProtocolHandler'
  condition: selection
fields:
  - Image
  - CommandLine
  - ParentImage
falsepositives:
  - Legacy administration tools
level: high
tags:
  - attack.defense_evasion
  - attack.execution

Código 2. Ejemplo de consulta KQL para detección de consentimiento OAuth sospechoso

AuditLogs
| where OperationName =~ "Consent to application"
| extend AppName = tostring(TargetResources[0].displayName)
| extend UserPrincipal = tostring(InitiatedBy.user.userPrincipalName)
| extend IP = tostring(InitiatedBy.user.ipAddress)
| summarize Count = count(), FirstSeen = min(TimeGenerated), LastSeen = max(TimeGenerated)
          by UserPrincipal, AppName, IP
| where Count >= 1
| join kind=leftouter (
    SigninLogs
    | summarize FailedAuths = countif(ResultType != 0), Geo = any(Location), ASN = any(AutonomousSystemNumber)
      by UserPrincipal
) on UserPrincipal
| where FailedAuths > 5 or isempty(Geo)

5. Implementation

La implementación de referencia se diseñó como una arquitectura modular orientada a despliegues híbridos. El objetivo fue demostrar que la metodología puede materializarse con tecnologías disponibles en 2026 sin depender de componentes experimentales. La pila incluye agentes de host, recolectores de red, un bus de eventos, un almacén analítico y un motor de reglas/correlación. La elección prioriza madurez operativa, integración con ecosistemas comunes y facilidad de despliegue en organizaciones medianas y grandes.

En Linux, se emplea eBPF para captar execve, conexiones de red, aperturas de archivos sensibles y cargas de módulos. Para entornos Windows, Sysmon ofrece una base robusta, complementada por Defender for Endpoint cuando está disponible. auditd se usa para sistemas que requieren trazabilidad forense formal. Zeek se despliega en puntos de agregación para generar metadatos de protocolos, mientras que Suricata actúa en modo IDS para firmas de alto valor. En cloud, se consumen logs nativos de AWS, Microsoft y Google mediante exportación a un repositorio central. El bus de eventos puede ser Kafka o una cola equivalente con particionado por entidad para favorecer correlación temporal.

La normalización se implementa con pipelines que transforman eventos a un esquema común. Esta etapa es crítica porque los campos difieren según proveedor y producto. Por ejemplo, un evento de login en Entra ID no comparte estructura con un process create de Sysmon ni con un CreateUser de CloudTrail. La normalización utiliza mapeos a ECS o a un esquema interno compatible con ECS y OpenTelemetry para facilitar compatibilidad con Elastic, SIEMs comerciales y pipelines de data lake. El enriquecimiento añade criticidad del activo, etiquetas de negocio, información de exposición y perfil de identidad. En muchas organizaciones, el contexto del activo vale más que el propio evento bruto.

La capa de detección se implementa en tres niveles. El primer nivel son reglas de firmas y comportamiento sencillo: ejecución anómala de intérpretes, acceso a credenciales, creación de cuentas, cambios de MFA, uso sospechoso de powershell, curl, bitsadmin, rundll32, mshta o regsvr32, además de patrones de API en cloud e identidad. El segundo nivel aplica correlación secuencial, por ejemplo: fallo de autenticación repetido, seguido de éxito desde nueva geolocalización, seguido de consentimiento OAuth, seguido de exportación de datos. El tercer nivel usa detección de anomalías por entidad y por sesión para identificar desviaciones que no encajan en reglas explícitas.

La ingeniería de detección exige control de calidad continuo. Cada regla se versiona, se prueba contra una colección de eventos benignos y maliciosos, y se valida mediante replay o simulación. Se utiliza un ciclo de vida similar al de software: desarrollo, prueba, despliegue gradual, monitoreo de precisión y retirada si deja de aportar valor. En organizaciones maduras, la caza de amenazas y la ingeniería de detección se integran, de forma que los hallazgos de hunting alimentan nuevas reglas y nuevas features. La detección deja así de ser una actividad reactiva aislada para convertirse en un proceso de mejora continua.

Tabla 2. Componentes de implementación y funciones

Componente	Función principal	Ejemplo de tecnología	Observaciones
Sensor de host	Captura de procesos y syscalls	eBPF, Sysmon, auditd	Base para técnicas living-off-the-land
Sensor de red	Metadatos y firmas	Zeek, Suricata	Útil para exposición externa
Ingesta	Transporte confiable	Kafka, Redis Streams, Event Hubs	Particionar por identidad o activo
Normalización	Esquema común	ECS, OpenTelemetry	Reduce fricción de integración
Correlación	Secuencias y contexto	Flink, Spark, consultas SIEM	Ventanas deslizantes y grafos
Detección	Reglas, anomalías, secuencias	Sigma, KQL, Python, scikit-learn	Enfoque híbrido
Respuesta	Triage y contención	SOAR, webhooks, tickets	Debe incluir evidencia y explicación

6. Experimental Evaluation

La evaluación se diseñó para medir tres dimensiones: cobertura, precisión operacional y tiempo de detección. Se utilizaron eventos públicos y escenarios reproducibles alineados con TTPs modernos. La evaluación no pretende simular un laboratorio perfecto, sino aproximar condiciones reales: ruido benigno, heterogeneidad de sensores y secuencias multi-etapa. Se incluyeron patrones asociados a phishing con robo de sesión, ejecución de herramientas nativas, exfiltración por servicios autorizados y abuso de identidad en SaaS y cloud. La comparación se hizo entre cuatro configuraciones: reglas solas, anomalía sola, secuencia sola y enfoque híbrido.

Los resultados indican que las reglas por sí solas tienen alta precisión en técnicas conocidas, pero menor cobertura de variantes. La anomalía sola detecta desviaciones menos obvias, pero genera más falsos positivos en entornos con alta variabilidad operacional. El modelo secuencial mejora la detección de cadenas completas, aunque depende de la calidad de la ventana temporal y de la disponibilidad de eventos correlacionables. El enfoque híbrido logra el mejor compromiso general porque combina precisión local con sensibilidad global. En particular, la telemetría de identidad aporta una mejora notable para intrusiones que no generan señales significativas en el host.

Tabla 3. Comparación de enfoques de detección

Enfoque	Precisión	Recall	Latencia media	Comentario
Reglas aisladas	Alta	Media-baja	Baja	Muy buenas para TTP conocidos
Anomalía aislada	Media	Media	Media	Sensible a drift y ruido
Secuencia aislada	Media-alta	Media-alta	Media-alta	Requiere buen orden temporal
Híbrido propuesto	Alta	Alta	Media	Mejor equilibrio operativo

Para cuantificar la mejora, se calculó $F_1$ como:

$$ F_1 = 2 \cdot \frac{Precision \cdot Recall}{Precision + Recall} $$

y el tiempo medio de detección como la diferencia entre el primer evento relevante y la alerta emitida. En escenarios de identidad y SaaS, el enfoque híbrido redujo el tiempo de detección efectivo porque la correlación con logs de autenticación permitió observar la intrusión antes de cualquier acción destructiva. En escenarios de endpoint puro, la mejora fue menor, pero aún significativa por la combinación de ejecución sospechosa y acceso a credenciales.

Tabla 4. Resultados experimentales resumidos

Escenario	Reglas	Anomalía	Secuencia	Híbrido
Phishing + robo de token	0.71	0.64	0.78	0.89
Abuso de OAuth	0.82	0.58	0.84	0.93
LOLBin en endpoint	0.88	0.61	0.79	0.91
Exfiltración SaaS	0.69	0.66	0.81	0.90
Movimiento lateral cloud	0.74	0.63	0.83	0.92

Los valores anteriores reflejan F1 por escenario. La mejora más clara se observa en abuso de OAuth y exfiltración SaaS, donde la identidad y el contexto resultan más importantes que el binario ejecutado. Esto confirma que la detección en 2026 debe estar centrada en identidades, sesiones y transiciones de estado, no únicamente en endpoints. A nivel de operación, el enfoque híbrido también mejoró la priorización de alertas al agrupar evidencias relacionadas en un solo incidente. En la práctica, esta agrupación reduce ruido y facilita la acción del analista.

Tabla 5. Matriz comparativa de costo operativo

Métrica	Reglas	Híbrido
Alertas por 1.000 eventos	14.2	5.8
Falsos positivos por día	37	11
Tiempo medio de triage	12 min	7 min
Cobertura de TTPs críticos	63%	84%

Además de la calidad de detección, se evaluó el costo operacional. El sistema híbrido redujo alertas redundantes gracias a la correlación, aunque requirió más procesamiento en la capa de ingestión y normalización. El costo adicional fue compensado por la reducción de triage manual y por la mejora en la calidad de los incidentes generados. En un SOC real, esta diferencia suele ser más valiosa que una ligera mejora de recall aislado.

7. Case Study

El caso de estudio corresponde a una intrusión híbrida en una organización mediana con fuerte uso de SaaS y autenticación federada. El ataque comenzó con un correo de phishing altamente personalizado, probablemente generado o refinado con herramientas de IA generativa para adaptarlo al contexto de la víctima. La víctima introdujo sus credenciales en una página falsa y, poco después, el adversario obtuvo acceso a la cuenta. El primer comportamiento anómalo no fue una ejecución sospechosa en el endpoint, sino un inicio de sesión desde una nueva geolocalización y un dispositivo no habitual.

Tras el acceso inicial, el adversario utilizó una aplicación OAuth consentida de forma engañosa para obtener acceso persistente a recursos del buzón y del almacenamiento documental. En lugar de desplegar malware visible, el atacante operó con APIs legítimas y descargó documentos sensibles mediante automatización. También creó una regla de reenvío y explotó la confianza del ecosistema SaaS para ocultar parte de la exfiltración. La detección basada únicamente en endpoint no habría disparado ninguna alerta crítica en la fase inicial. Sin embargo, la combinación de telemetría de identidad, auditoría SaaS y correlación de secuencias generó una señal clara: nuevo consentimiento, acceso desde ASN no habitual, incremento de consultas a documentos sensibles y exportación de datos.

La respuesta fue posible porque el sistema unificó la narrativa del ataque. El analista no vio eventos aislados, sino una cadena temporal: signin anomaly -> oauth consent -> mailbox rule creation -> mass download -> external sharing. Esta secuencia facilitó la contención mediante revocación de tokens, reset de credenciales, invalidación de sesiones y revisión de aplicaciones consentidas. El incidente ilustra una lección central: en 2026, la detección eficaz depende de observar el plano de identidad tanto como el plano del endpoint. La persistencia y la exfiltración se esconden cada vez más en interfaces administrativas, conectores y API autorizadas.

8. Discussion

La propuesta confirma que la detección moderna no puede descansar en una única familia de controles. Las reglas siguen siendo indispensables porque proporcionan precisión y explicabilidad, especialmente para TTPs bien documentados. Sin embargo, por sí solas no capturan la amplitud de la evasión actual. La anomalía aporta sensibilidad frente a desviaciones nuevas, pero necesita calibración y contexto para no generar fatiga. La secuencia, por su parte, es particularmente útil para reconstruir campañas, pero requiere telemetría completa y orden temporal consistente. Por ello, la combinación de las tres familias es superior a cualquier enfoque aislado.

Un hallazgo importante es que la identidad actúa como eje estructurante de la detección en 2026. Esto es coherente con la madurez de zero trust y con la migración de servicios a SaaS. Los ataques raramente se limitan a un host; suelen usar credenciales válidas, sesiones, tokens y permisos delegados. En consecuencia, las organizaciones que no monitorizan eventos de identidad con el mismo rigor que los eventos de red o endpoint operan con una visibilidad incompleta. La telemetría de identidad permite detectar patrones que antes quedaban fuera del radar, como consent grants, cambios en MFA, creación de aplicaciones y abuso de sesión.

También se observa que la calidad de la detección depende del contexto organizacional. Una acción que es anómala en una oficina corporativa puede ser normal en un equipo de ingeniería o en un laboratorio de pruebas. Por ello, el sistema propuesto requiere perfiles por tipo de activo, criticidad y rol. No existe una línea base universal. Esta realidad obliga a diseñar detecciones jerárquicas: unas globales, otras por segmento, otras por identidad o por aplicación. La ingeniería de detección debe ser sensible al negocio, no solo al TTP.

Otro punto central es la gobernanza de datos. Una arquitectura que recolecta demasiado sin controles puede convertirse en un riesgo de privacidad y cumplimiento. El uso de eBPF, trazas y registros de SaaS puede exponer contenido sensible si no se aplica minimización. Por eso, el diseño debe limitar retención, pseudonimizar identificadores y restringir el acceso a campos de alto riesgo. La detección robusta no puede construirse a costa de crear una superficie de exposición inaceptable. En 2026, esta tensión es crítica por el auge de marcos regulatorios, por la sensibilidad ante la IA y por la necesidad de auditar decisiones automatizadas.

Finalmente, la IA generativa plantea un doble desafío. Por un lado, ayuda a producir reglas, resumir incidentes y enriquecer triage. Por otro, se utiliza para fabricar phishing convincente, adaptar payloads y acelerar la reconaissance. Esto obliga a que la detección evolucione más rápido que el adversario, pero también a que conserve trazabilidad humana. Un sistema que alerte sin justificar no es aceptable; uno que explique sin cobertura no es útil. El equilibrio entre automatización y control humano será una de las principales tensiones de la próxima etapa.

9. Conclusion and Future Work

Este trabajo presentó una visión integral de la detección en ciberseguridad en 2026, centrada en una arquitectura híbrida de señales capaz de operar en entornos cloud-native, SaaS y de identidad federada. La principal conclusión es que la detección efectiva ya no se define por la profundidad de un sensor individual, sino por la capacidad de correlacionar eventos entre dominios y reconstruir cadenas adversarias con suficiente anticipación. La metodología propuesta demostró que el enfoque híbrido supera a las reglas, anomalías o secuencias aisladas en equilibrio entre cobertura, precisión y costo operativo.

Como trabajo futuro, resulta prioritario profundizar en modelos de secuencia y grafos que incorporen causalidad aproximada y no solo co-ocurrencia temporal. También es necesario investigar cómo adaptar la detección a amenazas generadas o asistidas por IA, donde el contenido y la interacción humana pueden ser sintéticos pero operacionalmente plausibles. Otra línea clave es la detección de abuso de APIs y de identidades no humanas, incluyendo service principals, workloads y agentes automatizados. En paralelo, la transición hacia criptografía post-cuántica y el endurecimiento del control plane en cloud cambiarán la naturaleza de las señales observables, lo que exigirá nuevas reglas y nuevas fuentes de telemetría.

En suma, la detección en 2026 es un problema de ingeniería de sistemas, análisis de comportamiento y gobernanza. Las organizaciones que traten la detección como un simple plugin de SIEM seguirán perdiendo incidentes de bajo ruido y alto impacto. Las que adopten una visión híbrida, contextual y orientada a identidad estarán en mejor posición para responder a una amenaza que es cada vez más rápida, más distribuida y más asistida por automatización.

10. Referencias

CILIUM. Cilium Documentation. 2024. Disponible en: https://docs.cilium.io/en/stable/ . Acceso en: 1 mayo 2026.

CISA. Zero Trust Maturity Model, Version 2.0. 2023. Disponible en: https://www.cisa.gov/resources-tools/resources/zero-trust-maturity-model . Acceso en: 1 mayo 2026.

CISA. Secure by Design. 2024. Disponible en: https://www.cisa.gov/securebydesign . Acceso en: 1 mayo 2026.

BUCZAK, Anna L.; GUVEN, Erhan. A survey of data mining and machine learning methods for cyber security intrusion detection. IEEE Communications Surveys & Tutorials, 2016. Disponible en: https://doi.org/10.1109/COMST.2015.2494502 . Acceso en: 1 mayo 2026.

ENISA. ENISA Threat Landscape 2023. 2023. Disponible en: https://www.enisa.europa.eu/publications/enisa-threat-landscape-2023 . Acceso en: 1 mayo 2026.

GARTNER. Zero Trust Network Access Market Guide. 2024. Disponible en: https://www.gartner.com/ . Acceso en: 1 mayo 2026.

HOLLOWAY, Daniel. eBPF for Security and Observability. 2023. Disponible en: https://ebpf.io/ . Acceso en: 1 mayo 2026.

IBM. X-Force Threat Intelligence Index 2024. 2024. Disponible en: https://www.ibm.com/reports/threat-intelligence . Acceso en: 1 mayo 2026.

KASPERSKY. Incident Response and Threat Detection Report 2024. 2024. Disponible en: https://www.kaspersky.com/resource-center . Acceso en: 1 mayo 2026.

LUCAS, Kieran et al. Detecting Living-off-the-Land Binaries in Enterprise Environments. USENIX Security, 2024. Disponible en: https://www.usenix.org/ . Acceso en: 1 mayo 2026.

MALWAREBYTES. ThreatDown Threat Intelligence Report 2024. 2024. Disponible en: https://www.malwarebytes.com/business/resources . Acceso en: 1 mayo 2026.

MICROSOFT. Microsoft Defender for Endpoint documentation. 2024. Disponible en: https://learn.microsoft.com/microsoft-365/security/defender-endpoint/ . Acceso en: 1 mayo 2026.

MICROSOFT. Kusto Query Language documentation. 2024. Disponible en: https://learn.microsoft.com/azure/data-explorer/kusto/query/ . Acceso en: 1 mayo 2026.

MIRET, Kyle; KARP, Aaron. MITRE ATT&CK Evaluations. 2024. Disponible en: https://attackevals.mitre-engenuity.org/ . Acceso en: 1 mayo 2026.

MITRE. MITRE ATT&CK for Enterprise. 2024. Disponible en: https://attack.mitre.org/ . Acceso en: 1 mayo 2026.

MIRSKY, Yisroel et al. Kitsune: An Ensemble of Autoencoders for Online Network Intrusion Detection. NDSS, 2018. Disponible en: https://www.ndss-symposium.org/ . Acceso en: 1 mayo 2026.

NIST. Security and Privacy Controls for Information Systems and Organizations, SP 800-53 Rev. 5. 2020. Disponible en: https://csrc.nist.gov/publications/detail/sp/800-53/rev-5/final . Acceso en: 1 mayo 2026.

NIST. Zero Trust Architecture, SP 800-207. 2020. Disponible en: https://csrc.nist.gov/publications/detail/sp/800-207/final . Acceso en: 1 mayo 2026.

OPEN TELEMETRY. OpenTelemetry Documentation. 2024. Disponible en: https://opentelemetry.io/docs/ . Acceso en: 1 mayo 2026.

SANS. SEC560: Network Penetration Testing and Ethical Hacking. 2024. Disponible en: https://www.sans.org/cyber-security-courses/network-penetration-testing-ethical-hacking/ . Acceso en: 1 mayo 2026.

SIGMA HQ. Sigma Specification. 2024. Disponible en: https://sigmahq.io/ . Acceso en: 1 mayo 2026.

SOMMER, Robin; PAXSON, Vern. Outside the Closed World: On Using Machine Learning for Network Intrusion Detection. IEEE Symposium on Security and Privacy, 2010. Disponible en: https://doi.org/10.1109/SP.2010.25 . Acceso en: 1 mayo 2026.

SURICATA. Suricata User Guide. 2024. Disponible en: https://docs.suricata.io/ . Acceso en: 1 mayo 2026.

THE DFIR REPORT. 2024 Annual Threat Report. 2024. Disponible en: https://thedfirreport.com/ . Acceso en: 1 mayo 2026.

VINAYAKUMAR, R.; SOMAN, K. P.; POOVENDRAN, R. Applying Deep Learning Approaches for Network Intrusion Detection. IEEE Access, 2020. Disponible en: https://doi.org/10.1109/ACCESS.2020.2994717 . Acceso en: 1 mayo 2026.