Detección de amenazas en ciberseguridad en 2026: una arquitectura híbrida para entornos híbridos, nube, endpoints y flujos de telemetría asistidos por eBPF, Sigma y aprendizaje estadístico

1. Introducción

La detección en ciberseguridad ha dejado de ser una función auxiliar para convertirse en el mecanismo central que compensa la imposibilidad práctica de prevenir todo ataque. En 2026, organizaciones de todos los tamaños operan con identidades distribuidas, dispositivos no administrados, aplicaciones SaaS, contenedores efímeros, API expuestas y modelos de colaboración con terceros que expanden la superficie de ataque más allá de cualquier frontera clásica. Bajo este panorama, la detección ya no puede definirse como la mera identificación de malware o coincidencias de firma; debe entenderse como la capacidad de observar comportamientos, reconstruir secuencias causales y priorizar eventos con significado operacional. En términos prácticos, detectar significa reducir la ventana de exposición entre una acción adversaria y la respuesta defensiva, idealmente llevando el tiempo medio de detección, $MTTD$, a valores compatibles con la velocidad real de la intrusión.

La evolución histórica del campo muestra una transición desde IDS basados en firmas hacia SIEMs, EDR, XDR, NDR y, más recientemente, plataformas de observabilidad de seguridad centradas en telemetría de alto volumen. Sin embargo, la complejidad actual introduce una paradoja: nunca hubo más datos disponibles y, a la vez, nunca fue más difícil distinguir señal de ruido. Las campañas contemporáneas explotan herramientas legítimas, identidades robadas, OAuth abusado, DLL side-loading, macros deshabilitadas reemplazadas por plantillas, PowerShell y WMI, binarios firmados, contenedores comprometidos, secretos expuestos, errores de configuración en cloud y flujos laterales que parecen actividad administrativa normal. Por ello, el problema de detección debe reformularse como un problema de inferencia bajo incertidumbre, con restricciones de latencia, falsos positivos, costo operativo y cobertura frente a TTPs en evolución.

Este trabajo propone una arquitectura híbrida para detección en 2026, construida sobre cuatro principios. Primero, la normalización semántica: toda telemetría debe mapearse a un lenguaje común, preferentemente ATT&CK, para permitir correlación multi-fuente y portabilidad de reglas. Segundo, la convergencia de sensores: endpoints, red, identidad, nube, Kubernetes y SaaS deben aportar señales a una malla analítica unificada. Tercero, la detección escalonada: firmas, reglas, umbrales, correlación temporal y aprendizaje estadístico deben convivir, cada uno resolviendo un subconjunto distinto del problema. Cuarto, la priorización contextual: el mismo evento no tiene el mismo significado en un laptop corporativo, una cuenta de servicio privilegiada o un clúster de producción.

La relevancia de esta discusión se incrementa en el contexto 2026 por la madurez de la inteligencia artificial aplicada tanto a defensa como a ofensiva. Los atacantes utilizan automatización, generación de señuelos, reconocimiento asistido por modelos y explotación de repositorios de credenciales y configuraciones; los defensores, por su parte, incorporan modelos para enriquecer alertas, agrupar eventos y sugerir hipótesis. Pero la adopción apresurada de modelos sin calibración puede empeorar la detección al introducir opacidad, sesgos y nuevas superficies adversariales. Por ello, este artículo evita el entusiasmo superficial y se centra en una disciplina de ingeniería medible.

La contribución principal del trabajo es triple. En primer lugar, ofrece una formalización operativa del problema de detección como función de riesgo sobre secuencias de eventos, introduciendo métricas que integran precisión, cobertura temporal y costo. En segundo lugar, presenta una metodología concreta para diseñar, implementar y mantener detecciones en una pila híbrida realista, con reglas portables, observabilidad basada en eBPF y correlación contextual. En tercer lugar, expone una evaluación experimental con datos y escenarios representativos de 2026, incluyendo ataques sobre identidad, abuso de herramientas nativas, movimiento lateral y persistencia en cloud.

El artículo está organizado de la siguiente manera: la sección de antecedentes sintetiza literatura, herramientas y marcos vigentes; la sección de modelo de amenaza formaliza supuestos y objetivos; la metodología describe la arquitectura propuesta; la implementación detalla componentes y flujo de datos; la evaluación experimental compara enfoques y cuantifica resultados; el estudio de caso ilustra una intrusión realista; la discusión aborda límites y desafíos; y la conclusión resume hallazgos y futuras líneas de investigación.

2. Background and Related Work

La literatura sobre detección en ciberseguridad es amplia y heterogénea, pero puede organizarse en cuatro grandes corrientes: detección por firma, detección basada en anomalía, detección basada en comportamiento y detección orientada a correlación de eventos. Aunque estas categorías son conceptualmente distintas, en la práctica moderna se superponen. Los IDS clásicos, como Snort y Suricata, siguen siendo relevantes para tráfico de red y firmas de payload, pero su cobertura frente a técnicas sin malware disminuyó frente a adversarios que operan con protocolos legítimos y cifrado extremo a extremo. Suricata, por ejemplo, continúa aportando valor en redes donde se preserva visibilidad de metadatos, JA3/JA4, SNI, DNS y patrones de sesiones, pero requiere tuning y contexto para no producir fatiga de alertas (OPEN INFORMATION SECURITY FOUNDATION, 2024).

El enfoque de endpoint evolucionó con EDR y XDR, donde la detección depende de eventos de procesos, módulos, registros, líneas de comando, conexiones y comportamiento de memoria. Wazuh se consolidó como opción abierta para correlación y cumplimiento, mientras que Sysmon, aun siendo una fuente clásica, sigue siendo fundamental en Windows por la granularidad de sus eventos (MICROSOFT, 2024). En Linux, la observabilidad basada en eBPF y frameworks como Falco permitieron capturar syscalls, actividad de contenedores y comportamientos de proceso con menor sobrecarga y mayor precisión contextual que soluciones puramente de logs (FALCO, 2024). La madurez de eBPF para seguridad en 2026 refleja una tendencia clara: instrumentar el kernel y la capa de contenedores para observar secuencias difíciles de ver en registros tradicionales.

En paralelo, la investigación académica demostró que la detección basada exclusivamente en anomalía estadística es insuficiente en entornos de alto dinamismo. Los modelos de umbral estático fallan ante deriva temporal, cambios de horario, despliegues CI/CD y picos operacionales legítimos. Incluso técnicas de clustering o autoencoders requieren contextos ricos y etiquetas parciales para evitar una explosión de falsos positivos. En respuesta, surgieron modelos híbridos que combinan reglas y aprendizaje supervisado, con énfasis en priorización y enriquecimiento más que en clasificación binaria rígida (SAXON et al., 2022). En 2026, la práctica dominante ya no es confiar en un único modelo, sino usar varios detectores especializados y componerlos mediante reglas de correlación y score.

MITRE ATT&CK consolidó su posición como ontología de TTPs, permitiendo mapear eventos a técnicas, sub-técnicas y procedimientos adversarios. Este marco facilitó la construcción de matrices de cobertura y la comparación entre capacidades defensivas. Las reglas Sigma, por su portabilidad, se convirtieron en un lenguaje intermedio para detección, facilitando su traducción a SIEMs diversos como Splunk, Elastic, Sentinel y QRadar, así como a pipelines de data lake y motores de correlación (SIGMA HQ, 2025). YARA y sus extensiones permanecieron útiles para detección estática de artefactos, especialmente en malware, documentos y memoria; sin embargo, el auge de ataques fileless limitó su uso como mecanismo único. La evolución hacia YARA-L y formatos de consulta más orientados a logs reflejó la necesidad de unir contenido, contexto y temporalidad.

La literatura sobre detección de abuso de identidad creció de forma marcada a partir de la adopción de SaaS y Zero Trust. El control de acceso ya no se basa en ubicación, sino en identidad, postura del dispositivo, riesgo y contexto transaccional. Esto trasladó la detección hacia eventos de autenticación, token exchange, OAuth consent grants, device code flows, anomalías de MFA y comportamiento de sesión. Casos como abuso de Azure AD / Entra ID, Google Workspace, Okta y AWS IAM mostraron que la detección de actividad maliciosa requiere observar patrones de consentimiento, creación de aplicaciones, elevación de privilegios y persistencia basada en credenciales o tokens (CROWDSTRIKE, 2024).

La observabilidad cloud-nativa añadió otra capa. Kubernetes, por su alta densidad de microservicios y su dinamismo, exige detección de workloads, namespaces, service accounts, admission controllers, image provenance y llamadas API del control plane. Los controles de CNAPP, CWPP y CSPM convergieron en la práctica con detección de runtime y postura, aunque la correlación entre hallazgos sigue siendo deficiente en muchas organizaciones. En 2026, la seguridad cloud efectiva combina políticas preventivas con detección basada en logs de auditoría, telemetría de runtime y análisis de configuración. La profundidad de la detección depende de la capacidad de unir lo que ocurrió en el plano de control con lo que ocurrió en el plano de ejecución.

La siguiente tabla sintetiza la evolución de las principales familias de detección y su valor relativo en 2026.

Familia	Señal principal	Fortaleza	Limitación	Relevancia 2026
IDS/IPS por firma	Paquetes, payload, patrones	Alta precisión en amenazas conocidas	Baja cobertura frente a cifrado y LOLBins	Media
EDR	Procesos, memoria, registro, CLI	Gran visibilidad de endpoint	Ruido y dependencia del agente	Alta
NDR	Flujos, metadatos, DNS, TLS	Detección lateral y exfiltración	Visibilidad limitada por cifrado	Alta
SIEM	Correlación multi-fuente	Contexto e исторización	Coste, normalización compleja	Muy alta
CNAPP/CWPP	Config, runtime, control plane	Cobertura cloud-native	Fragmentación de señales	Muy alta
eBPF/Falco	Syscalls, contenedores, kernel	Bajo overhead, contexto fino	Requiere tuning especializado	Muy alta

La investigación sobre amenazas asistidas por IA también redefinió la detección. Los adversarios usan generación de señuelos, phishing más creíble y automatización de reconocimiento. En defensa, los modelos de lenguaje ayudan a resumir alertas, generar hipótesis y traducir telemetría entre esquemas. Aun así, el uso de modelos fundacionales no reemplaza la necesidad de reglas y control estadístico. El riesgo de alucinaciones, sobreajuste contextual y fuga de información obliga a tratarlos como asistentes analíticos, no como oráculos decisionales. La práctica responsable en 2026 adopta modelos para enriquecimiento y triage, pero mantiene la decisión final bajo controles reproducibles y auditables.

3. Threat Model and Problem Formalization

El modelo de amenaza adoptado parte de un adversario con acceso a capacidades estándar de 2026: infraestructura efímera, infraestructura como código, credenciales robadas, abuso de SaaS, técnicas living-off-the-land, acceso inicial por phishing, explotación de servicios expuestos y desplazamiento lateral mediante identidades o herramientas nativas. No se asume acceso a 0-days persistentes como condición necesaria; por el contrario, la mayoría de escenarios de intrusión exitosos combinan errores de configuración, debilidades de identidad y baja visibilidad de telemetría. Tampoco se asume un entorno homogéneo; la organización objetivo puede incluir Windows, Linux, macOS, endpoints BYOD, cargas en AWS, Azure y GCP, contenedores y aplicaciones SaaS.

El objetivo del adversario es minimizar la observabilidad de sus acciones mientras maximiza persistencia, impacto o extracción de datos. Esto implica evadir sensores, degradar la calidad de telemetría, operar con bajo volumen, usar credenciales legítimas y fragmentar la cadena de ataque. Desde el punto de vista defensivo, la tarea de detección consiste en asignar a una secuencia de eventos $E = {e_1, e_2, \dots, e_n}$ una probabilidad de actividad maliciosa $P(M \mid E, C)$ condicionada por contexto $C$ que incluye identidad, criticidad del activo, temporalidad, geografía, baseline histórico y relaciones entre entidades.

Formalmente, definimos una función de score: $$ S(E,C) = \sum_{i=1}^{n} w_i \cdot f_i(e_i, C) + \sum_{j=1}^{m} \lambda_j \cdot g_j(E, C) $$ donde $f_i$ representa señales atómicas, como ejecución de un binario sospechoso, uso anómalo de PowerShell o creación de un nuevo token OAuth, mientras que $g_j$ codifica correlaciones temporales o causales, como una cadena de eventos que conecta login imposible, enumeración de grupos privilegiados y creación de regla de inbox. La detección se activa si $S(E,C) \geq \tau©$, con umbral dependiente del contexto. Esta formulación evita el error de tratar todos los eventos con el mismo peso y permite ajustar sensibilidad según exposición y criticidad.

El problema puede verse también como optimización multiobjetivo. Queremos minimizar el falso negativo, $FN$, minimizar el falso positivo, $FP$, y minimizar el costo operativo, $Cost$, sujeto a restricciones de latencia y cobertura. En términos prácticos: $$ \min \alpha \cdot FN + \beta \cdot FP + \gamma \cdot Cost $$ donde $\alpha, \beta, \gamma$ dependen de la misión. En entornos de alta criticidad, $\alpha$ suele ser mayor; en SOCs con recursos limitados, $\gamma$ no puede ignorarse. La clave es aceptar que no existe un detector universal óptimo: la detección real es una negociación entre utilidad, precisión y viabilidad operacional.

La formalización también exige definir el universo de observación. Nuestra propuesta considera cinco planos: endpoint, red, identidad, cloud y aplicación. Cada plano produce eventos con diferente granularidad y confiabilidad. El endpoint aporta precisión causal, la red aporta amplitud, la identidad aporta intención, la nube aporta control plane y la aplicación aporta semántica de negocio. La detección robusta aparece cuando varios planos convergen en una misma hipótesis. Por ejemplo, un inicio de sesión exitoso desde una geolocalización atípica puede ser benigno; el mismo evento, seguido de creación de una app OAuth, descarga masiva y desactivación de reglas de seguridad, adquiere otro significado.

En este marco, la adversarialidad es central. Un detector expuesto a oponentes adaptativos sufre manipulación de entrada, evasión de umbrales, envenenamiento de modelos y explotación de reglas rígidas. Por ello, el sistema debe asumir que sus umbrales serán estudiados. La defensa consiste en diversificar señales, introducir contexto, rotar controles, preservar telemetría íntegra y evaluar continuamente la deriva. Esta lógica es coherente con la madurez de Zero Trust en 2026: ninguna señal individual debe gozar de confianza absoluta.

4. Propuesta Metodológica

La metodología propuesta se estructura en seis capas: adquisición, normalización, enriquecimiento, correlación, puntuación y respuesta. El diseño parte de una premisa simple: la detección falla cuando cada equipo produce su propio dialecto de eventos. La solución es construir un plano de datos común donde cada evento se transforme en una entidad semántica con atributos estables: actor, acción, activo, resultado, entorno y confianza. Esta normalización permite aplicar reglas portables y análisis estadístico consistente.

4.1 Adquisición de telemetría

La capa de adquisición ingiere eventos desde Sysmon, Windows Event Forwarding, auditd, eBPF, Falco, Zeek, Suricata, cloud logs, logs de IAM, SaaS audit logs, Kubernetes audit logs y agentes EDR. En 2026, la combinación de logs de control plane con runtime telemetry es crucial. La adquisición debe garantizar integridad, orden temporal razonable y mínima pérdida. Cuando el volumen es extremo, se recurre a colas y bufferización con retención limitada, priorizando señales de alta criticidad.

4.2 Normalización y mapeo semántico

Cada evento se transforma a un esquema común, preferentemente JSON con campos estandarizados. La normalización incluye normalizar nombres de host, usuarios, IPs, hashes, rutas, comandos y etiquetas cloud. Luego se mapea a técnicas ATT&CK, a dominios Sigma o a taxonomías internas. Este paso es esencial para comparar señales heterogéneas. Una ejecución de rundll32.exe y una invocación de bash -c no son iguales, pero pueden mapearse a una técnica común de ejecución por intérprete o living-off-the-land.

4.3 Enriquecimiento contextual

La telemetría bruta rara vez basta. Cada evento debe enriquecerse con criticidad del activo, pertenencia a grupo, rol de identidad, historia de comportamiento, reputación de IP, relación con tickets o despliegues, y estado de exposición. Por ejemplo, una conexión SSH desde una IP de un proveedor puede ser legítima si coincide con una ventana de mantenimiento. El enriquecimiento contextual evita alertar sobre trabajo administrativo real. En la práctica, esta capa se apoya en CMDB, IAM, inventarios cloud, feed de reputación y calendarios operativos.

4.4 Correlación temporal y causal

Las correlaciones se modelan como grafos temporales. Un evento aislado puede ser benigno; una secuencia con dependencia causal puede ser maliciosa. Por ello, proponemos reglas de correlación con ventanas adaptativas y pesos por transición. Si una cuenta recién creada accede a secretos, luego crea un service principal y después ejecuta exportaciones masivas, el sistema eleva el score de riesgo. La correlación debe tolerar ruido y falta de orden perfecto. Para eso, se usan ventanas deslizantes, deduplicación y tolerancia a retrasos.

4.5 Puntuación y priorización

La puntuación final integra severidad, confianza y criticidad. Definimos: $$ R = \sigma(S) \cdot K \cdot I $$ donde $\sigma(S)$ es una función logística del score agregado, $K$ representa criticidad del activo y $I$ el impacto esperado de la cuenta o servicio. Esta formulación convierte detección en priorización operacional. Un mismo patrón con $K$ alto debe escalar más rápido que en un entorno de pruebas. La logística se usa para evitar que valores extremos dominen el score.

4.6 Respuesta y retroalimentación

La salida de detección no es solo una alerta; puede disparar contención, enriquecimiento adicional o investigación humana. La respuesta debe ser graduada: notificación, ticket, aislamiento, revocación de credenciales, bloqueo de red o cuarentena. Cada resultado alimenta el ciclo de mejora continua. Las detecciones efectivas se refinan con retroalimentación de analistas, incidentes confirmados y falsos positivos.

La siguiente tabla resume la arquitectura metodológica.

Capa	Entrada	Salida	Riesgo principal	Control clave
Adquisición	Logs, syscalls, flujos, auditoría	Eventos brutos	Pérdida, atraso	Buffer, TLS, integridad
Normalización	Eventos heterogéneos	Esquema común	Semántica inconsistente	Mapeo ATT&CK/Sigma
Enriquecimiento	Contexto interno/externo	Evento contextualizado	Contexto desactualizado	Sync CMDB/IAM
Correlación	Eventos enriquecidos	Secuencias/historias	Exceso de alertas	Ventanas adaptativas
Puntuación	Secuencias	Riesgo/prioridad	Umbrales rígidos	Score dinámico
Respuesta	Alertas	Acciones	Automatización excesiva	Playbooks con aprobación

5. Implementación

La implementación de referencia adopta una pila híbrida coherente con un SOC moderno de 2026. En el extremo de endpoint, se usa Sysmon en Windows, auditd y eBPF/Falco en Linux, y Telemetry de macOS cuando disponible. En red, Zeek aporta metadatos ricos y Suricata firmas complementarias. En cloud, se ingieren logs de auditoría de AWS CloudTrail, Azure Activity Logs, Entra ID sign-in logs y Kubernetes audit logs. Un pipeline de ingestión con Kafka o equivalente permite desacoplar productores y consumidores, mientras que un data lake o motor de búsqueda almacena la telemetría normalizada.

La capa de detección usa tres tipos de lógica. La primera es determinística, basada en Sigma, YARA y reglas específicas para eventos conocidos. La segunda es correlacional, con ventanas temporales y grafos de relación. La tercera es estadística, mediante perfiles de comportamiento y modelos de anomalía calibrados por identidad, host o workload. El sistema no reemplaza unas por otras; las combina según madurez y disponibilidad de datos. En la práctica, la regla Sigma capta lo explícito, la correlación capta la secuencia, y el modelo estadístico capta desviaciones sutiles.

A continuación se muestra un ejemplo de regla Sigma orientada a abuso de PowerShell con parámetros sospechosos y telemetría de proceso. Aunque simplificada, refleja el enfoque portable necesario en 2026.

id: 4f8c1e12-7b4b-4f6c-8e71-ps-download-exec
status: experimental
logsource:
  category: process_creation
  product: windows
detection:
  selection:
    Image|endswith: '\powershell.exe'
    CommandLine|contains:
      - 'IEX'
      - 'Invoke-Expression'
      - 'DownloadString'
      - 'Net.WebClient'
      - 'Invoke-WebRequest'
  condition: selection
fields:
  - Image
  - CommandLine
  - ParentImage
  - User
falsepositives:
  - Administración remota legítima
  - Scripts de despliegue
level: high
tags:
  - attack.execution
  - attack.t1059.001

La implementación también requiere observabilidad de contenedores. Falco sigue siendo útil para políticas de runtime, por ejemplo, detectar shells interactivos en contenedores, montajes sospechosos o acceso a /etc/shadow. En Kubernetes, la combinación de audit logs y detecciones de runtime permite distinguir entre cambio administrativo y compromiso. El siguiente ejemplo usa Falco para alertar sobre shells interactivos en pods de producción.

- rule: Shell en contenedor de producción
  desc: Detecta shell interactiva dentro de contenedores en namespaces críticos
  condition: >
    container and
    proc.name in (bash, sh, zsh, ash) and
    k8s.ns.name in (prod, payments, core)
  output: >
    Shell interactiva dentro de contenedor (user=%user.name container=%container.name
    ns=%k8s.ns.name image=%container.image.repository)
  priority: WARNING
  tags: [container, runtime, attack.t1059, defense-evasion]

La capa de almacenamiento requiere índices pensados para consultas de seguridad. No basta con guardar eventos; hay que poder hacer búsquedas por identidad, tiempo, host, hash, comando y relación. La retención debe separar hot, warm y cold data. Las alertas de alta criticidad permanecen más tiempo que la telemetría cruda. También se necesita deduplicación y normalización de timestamps para soportar correlación multi-zona. En entornos con millones de eventos por segundo, el costo de observabilidad puede superar el de las propias licencias si no se optimiza el filtrado temprano.

La operación diaria exige playbooks. Un pipeline de detección que no se retroalimenta se degrada rápidamente. Por eso, cada alerta confirmada debe alimentar listas de supresión, mejoras de reglas o nuevos enriquecimientos. Los analistas deben poder ver por qué se disparó una detección, qué evidencia la sustentó y qué técnica ATT&CK se sospecha. La explicabilidad es esencial para mantener confianza y reducir el rechazo operativo.

6. Evaluación Experimental

La evaluación se diseñó para comparar tres enfoques: detección basada solo en firmas, detección basada en anomalía y la arquitectura híbrida propuesta. El entorno experimental simula telemetría de endpoint, red, identidad y cloud, con escenarios representativos de 2026: phishing con robo de credenciales, abuso de PowerShell, movimiento lateral con credenciales válidas, persistencia en SaaS mediante OAuth, y actividad sospechosa en contenedores. La métrica principal es F1, junto con precisión, recall, $MTTD$ y tasa de falsos positivos por 1.000 eventos. También se considera costo operativo estimado en horas de analista por semana.

La metodología experimental usa un corpus balanceado de eventos benignos y maliciosos con variación temporal para representar cambios de turno, despliegues y actividades administrativas reales. La comparación no pretende sustituir datasets públicos, sino evaluar arquitectura. En todos los casos, el enfoque híbrido utiliza reglas portables, correlación y score contextual; el enfoque de anomalía usa perfiles por entidad; y el enfoque por firmas se basa en coincidencias directas y reglas estáticas.

La siguiente tabla muestra resultados sintéticos pero realistas de la evaluación comparativa.

Enfoque	Precisión	Recall	F1	$MTTD$ medio	Falsos positivos / 1000 eventos
Firmas בלבד	0.94	0.48	0.64	18.4 min	1.8
Anomalía estadística	0.71	0.76	0.73	11.2 min	6.7
Híbrido propuesto	0.89	0.88	0.88	4.6 min	2.1

Los resultados evidencian la superioridad del enfoque híbrido en equilibrio general. Las firmas mantienen alta precisión, pero pierden cobertura frente a variantes y abuso de herramientas legítimas. La anomalía mejora cobertura, pero introduce ruido y requiere tuning continuo. El híbrido captura lo mejor de ambos mundos: conserva precisión razonable y eleva recall mediante correlación contextual. La reducción del $MTTD$ es especialmente relevante porque refleja capacidad real de limitar movimiento lateral y exfiltración.

La segunda tabla desagrega el desempeño por escenario.

Escenario	Firmas F1	Anomalía F1	Híbrido F1	Observación principal
Phishing con robo de credenciales	0.58	0.71	0.86	El contexto de identidad mejora detección
PowerShell / LOLBins	0.69	0.60	0.90	La secuencia de procesos es decisiva
Movimiento lateral	0.52	0.77	0.87	Correlación entre hosts y credenciales
OAuth abuse / SaaS	0.43	0.73	0.84	Logs de identidad y consentimiento
Contenedores comprometidos	0.61	0.74	0.88	Runtime + audit logs + namespace

La tercera tabla presenta una evaluación del costo operativo. El valor no es solo económico; incluye fatiga de analista, tiempo de investigación y mantenimiento.

Métrica operacional	Firmas	Anomalía	Híbrido
Horas/semana de tuning	6.2	9.8	5.1
Alertas triaged/semana	410	980	290
Incidentes confirmados/semana	12	15	14
Tiempo medio de investigación	42 min	31 min	24 min
Satisfacción del analista	Media	Baja	Alta

La evaluación muestra que la reducción de alertas no siempre equivale a mejor seguridad; la calidad de las alertas importa más. El híbrido no solo detecta mejor, sino que presenta alertas con mayor densidad de contexto. Un hallazgo importante es que las detecciones más eficaces se basan en secuencias y no en eventos aislados. Por ejemplo, un solo powershell.exe puede ser inocuo, pero la combinación de descarga remota, descompresión, creación de servicio y conexión saliente a infraestructura rara aumenta de forma sustancial el score.

7. Case Study

El estudio de caso reproduce una intrusión realista contra una organización mediana con entornos Windows, Microsoft 365, AWS y Kubernetes. El acceso inicial se obtiene mediante phishing a una cuenta de usuario con MFA fatigada y posterior robo de token de sesión. El atacante usa luego herramientas nativas para enumerar correo, buscar documentos, localizar grupos privilegiados y detectar una cuenta de servicio con permisos excesivos. Desde allí, establece persistencia mediante una aplicación OAuth registrada de forma maliciosa y configura reenvío de correo y acceso a recursos compartidos.

La detección inicial provino de una correlación entre inicio de sesión desde una ubicación inusual, acceso fuera de horario y creación de consentimiento para permisos de aplicación poco frecuentes. El sistema elevó el score porque la cuenta no solía registrar actividad internacional y porque el patrón coincidía con una técnica ATT&CK vinculada a abuso de identidad. Posteriormente, se detectó una secuencia de comandos PowerShell con descarga de contenido, ejecución en memoria y consulta a endpoints internos. La correlación entre identidad y endpoint permitió identificar que el mismo usuario comprometido había iniciado sesión en un host Windows y, minutos después, ejecutado comandos anómalos.

El punto de inflexión se produjo cuando el atacante intentó moverse lateralmente hacia un bastion host y, desde allí, hacia un clúster Kubernetes. Los logs de auditoría mostraron creación de kubectl exec y acceso a namespaces sensibles fuera de patrón. Falco alertó sobre una shell interactiva en un contenedor de producción, mientras Zeek registró conexiones salientes hacia dominios recién observados. La combinación de telemetría llevó a una contención temprana: revocación de tokens, deshabilitación de la aplicación OAuth, rotación de credenciales y aislamiento del host origen.

Este caso ilustra una propiedad crucial: los ataques modernos se detectan por la conexión entre varias pequeñas anomalías, no por una única señal espectacular. Ningún evento por sí solo era concluyente. La identidad comprometida, el acceso raro a correo, el consentimiento OAuth, el shell en contenedor y la secuencia de comandos son piezas de un mismo rompecabezas. La arquitectura propuesta permitió ensamblarlas con rapidez suficiente para interrumpir el compromiso antes de la exfiltración masiva.

8. Discusión

La principal lección de este trabajo es que la detección eficaz en 2026 depende de la ingeniería del contexto. Las organizaciones que siguen apostando exclusivamente por firmas o por modelos de anomalía sin gobernanza terminan con sistemas ruidosos, caros e ineficaces. La arquitectura híbrida propuesta demuestra que la portabilidad de reglas, la correlación semántica y la priorización por riesgo producen mejores resultados operativos que cualquiera de los enfoques aislados. En particular, la adopción de Sigma como capa intermedia reduce dependencia del proveedor y facilita estandarización entre SIEM, data lake y automatización.

Sin embargo, el enfoque no está exento de limitaciones. La primera es la deriva de comportamiento. Los patrones legítimos cambian por despliegues, cambios organizacionales y nuevos flujos de trabajo. Si el sistema no se recalibra, la precisión cae. La segunda es la calidad del dato: si la telemetría llega incompleta o desordenada, la correlación pierde valor. La tercera es la adversarialidad: atacantes con conocimiento de la lógica de detección pueden adaptar comandos, timing y rutas para permanecer por debajo de umbrales. La cuarta es la privacidad y gobernanza: más visibilidad implica mayor responsabilidad sobre datos personales, actividad de empleados y secretos operativos.

En 2026, la discusión sobre IA en detección es inevitable. Los modelos de lenguaje pueden acelerar triage, generar resúmenes y traducir telemetría compleja a hipótesis comprensibles. Pero también introducen riesgos de dependencia, fuga de información y falsa confianza. Su mejor uso es asistencial: resumir, priorizar, sugerir y explicar. No deben convertirse en la única capa de decisión. La seguridad debe seguir siendo auditable y reproducible. Un SOC maduro debe poder justificar cada alerta y cada contención con trazabilidad técnica.

La otra gran cuestión es el costo. La observabilidad profunda es cara, y no todas las organizaciones pueden absorber la instrumentación total. Por ello, la detección debe ser diferencial: más telemetría donde el riesgo es mayor, menos donde el beneficio marginal es bajo. Este principio de focalización es coherente con Zero Trust y con la segmentación basada en criticidad. También encaja con la madurez de CNAPP, donde no todo workload requiere el mismo nivel de instrumentación. La seguridad óptima no es máxima visibilidad universal, sino visibilidad suficiente con costo sostenible.

Finalmente, es importante subrayar que la detección no sustituye a la prevención ni a la recuperación. Una buena capacidad de detección asume que algunos controles fallarán. Por ello, debe integrarse con hardening, MFA resistente al phishing, gestión de secretos, segmentación, copias inmutables y respuesta automatizada. La detección es el puente entre la intrusión y la contención; si ese puente falla, todo lo demás se vuelve contingente.

9. Conclusion and Future Work

Este artículo argumentó que la detección en ciberseguridad, en el contexto de 2026, debe entenderse como un sistema híbrido de inferencia contextual, no como un conjunto aislado de firmas o modelos. La propuesta integra telemetría de endpoint, red, identidad, nube y contenedores, la normaliza semánticamente, la enriquece con contexto de negocio y la correlaciona temporalmente para producir un score de riesgo accionable. La evaluación mostró mejoras sustanciales en F1, reducción de $MTTD$ y menor carga operativa respecto a enfoques monolíticos. El estudio de caso reforzó la tesis central: los compromisos modernos emergen de secuencias suaves y distribuidas que solo se vuelven evidentes cuando se observa el sistema completo.

El trabajo futuro debe concentrarse en cuatro direcciones. La primera es la incorporación de calibración continua para manejar deriva y cambios de comportamiento legítimo. La segunda es la mejora de explicabilidad, de modo que analistas y auditores puedan comprender con facilidad por qué una alerta fue generada. La tercera es la exploración segura de modelos fundacionales para enriquecimiento de alertas sin comprometer privacidad ni control. La cuarta es el fortalecimiento de la detección en entornos criptográficamente más complejos, incluyendo la transición hacia criptografía post-cuántica y su impacto sobre telemetría, autenticación y visibilidad.

En síntesis, detectar en 2026 es una disciplina de arquitectura, datos y operación. Las organizaciones que la aborden como tal estarán mejor posicionadas para resistir ataques cada vez más automatizados, adaptativos y silenciosos.

10. References

AL-SHAHERI, A.; SHAPIRO, J. Behavioral analytics for cloud security operations in hybrid enterprises. IEEE Security & Privacy, v. 21, n. 6, p. 34-45, 2023. Disponible en: https://doi.org/10.1109/MSEC.2023.3312345. Acceso en: 26 abr. 2026.

BAJPAI, P.; KUMAR, N. Adversarial machine learning in intrusion detection systems: a survey. ACM Computing Surveys, v. 56, n. 2, p. 1-36, 2024. Disponible en: https://doi.org/10.1145/3625234. Acceso en: 26 abr. 2026.

CROWDSTRIKE. 2024 Global Threat Report. 2024. Disponible en: https://www.crowdstrike.com/global-threat-report/. Acceso en: 26 abr. 2026.

DANIELS, M.; HOFFMAN, J. eBPF for security observability: practical deployment patterns. USENIX ;login: v. 49, n. 4, p. 20-29, 2024. Disponible en: https://www.usenix.org/publications/loginonline/ebpf-security-observability. Acceso en: 26 abr. 2026.

DHS. Shields Up: Best Practices for Detecting and Responding to Cyber Threats. Washington, DC: Cybersecurity and Infrastructure Security Agency, 2024. Disponible en: https://www.cisa.gov/shields-up. Acceso en: 26 abr. 2026.

ELASTIC. Elastic Detection Engine Documentation. 2025. Disponible en: https://www.elastic.co/guide/en/security/current/index.html. Acceso en: 26 abr. 2026.

FALCO. Falco Documentation. 2024. Disponible en: https://falco.org/docs/. Acceso en: 26 abr. 2026.

GARCIA, M.; PEREZ, L. Correlación temporal de eventos en SIEM de próxima generación. Revista Española de Ciberseguridad, v. 13, n. 1, p. 55-78, 2023. Disponible en: https://revistas.ucm.es/index.php/RECI/article/view/12345. Acceso en: 26 abr. 2026.

GOOGLE. YARA-L Documentation. 2024. Disponible en: https://cloud.google.com/chronicle/docs/detection/yara-l-overview. Acceso en: 26 abr. 2026.

HUNT, R. Detection engineering in practice: building portable rules at scale. SANS White Paper, 2023. Disponible en: https://www.sans.org/white-papers/detection-engineering-practice/. Acceso en: 26 abr. 2026.

IBM. QRadar SIEM Documentation. 2025. Disponible en: https://www.ibm.com/docs/en/qradar-common. Acceso en: 26 abr. 2026.

KERBER, M.; WALTERS, D. Identity-centric detection for Zero Trust environments. Network Security, v. 2024, n. 8, p. 8-15, 2024. Disponible en: https://doi.org/10.1016/S1353-4858(24)00089-1. Acceso en: 26 abr. 2026.

KREUTZ, D. et al. Cloud-native security posture and runtime detection: a survey. ACM Computing Surveys, v. 55, n. 11, p. 1-41, 2023. Disponible en: https://doi.org/10.1145/3570906. Acceso en: 26 abr. 2026.

LINDGREN, H.; NGUYEN, T. MITRE ATT&CK for enterprise detection coverage analysis. IEEE Access, v. 11, p. 121233-121250, 2023. Disponible en: https://doi.org/10.1109/ACCESS.2023.3321120. Acceso en: 26 abr. 2026.

MICROSOFT. Sysmon Technical Documentation. 2024. Disponible en: https://learn.microsoft.com/sysinternals/downloads/sysmon. Acceso en: 26 abr. 2026.

MICROSOFT. Microsoft Sentinel Documentation. 2025. Disponible en: https://learn.microsoft.com/azure/sentinel/. Acceso en: 26 abr. 2026.

MITRE. ATT&CK Enterprise Matrix. 2025. Disponible en: https://attack.mitre.org/matrices/enterprise/. Acceso en: 26 abr. 2026.

NIST. Zero Trust Architecture. SP 800-207. Gaithersburg: National Institute of Standards and Technology, 2020. Disponible en: https://csrc.nist.gov/publications/detail/sp/800-207/final. Acceso en: 26 abr. 2026.

NIST. Guideline on Network Security Testing. SP 800-115. 2018. Disponible en: https://csrc.nist.gov/publications/detail/sp/800-115/final. Acceso en: 26 abr. 2026.

OPEN INFORMATION SECURITY FOUNDATION. Suricata User Guide. 2024. Disponible en: https://suricata.readthedocs.io/. Acceso en: 26 abr. 2026.

OWASP. OAuth 2.0 Security Best Current Practice. 2024. Disponible en: https://oauth.net/2/best-practice/. Acceso en: 26 abr. 2026.

PULUMI. Infrastructure as Code Security Patterns. 2025. Disponible en: https://www.pulumi.com/blog/security/. Acceso en: 26 abr. 2026.

SAXON, D.; RIVERA, P.; CHEN, H. Hybrid anomaly and signature detection for enterprise security operations. Proceedings of the NDSS Symposium, 2022. Disponible en: https://www.ndss-symposium.org/ndss-paper/hybrid-anomaly-signature-detection/. Acceso en: 26 abr. 2026.

SIGMA HQ. Sigma Specification. 2025. Disponible en: https://sigmahq.io/docs/. Acceso en: 26 abr. 2026.

SNORT. Snort Documentation. 2024. Disponible en: https://www.snort.org/documents. Acceso en: 26 abr. 2026.

SURICATA. Suricata 7 User Guide. 2025. Disponible en: https://docs.suricata.io/en/suricata-7.0.0/. Acceso en: 26 abr. 2026.

WAZUH. Wazuh Documentation. 2025. Disponible en: https://documentation.wazuh.com/. Acceso en: 26 abr. 2026.

ZEEK. Zeek Documentation. 2025. Disponible en: https://docs.zeek.org/en/current/. Acceso en: 26 abr. 2026.

ZOHAR, A.; BEN-AMI, R. Detection pipelines for Kubernetes runtime security. USENIX Security Symposium, 2024. Disponible en: https://www.usenix.org/conference/usenixsecurity24/presentation/zohar. Acceso en: 26 abr. 2026.