Detección de amenazas en ciberseguridad en 2026: formalización, arquitectura híbrida y evaluación de una canalización multimodal para entornos híbridos y nativos de la nube

1. Introducción

La detección es el núcleo operativo de la defensa moderna en ciberseguridad porque convierte observaciones dispersas en decisiones accionables. Sin detección efectiva, la prevención se degrada con rapidez ante un adversario que itera, prueba rutas alternativas, abusa de la identidad y opera con un conocimiento creciente de las defensas. En 2026, esto resulta aún más evidente porque la frontera entre infraestructura, software y usuario se ha difuminado. La identidad se ha convertido en el nuevo perímetro, las cargas de trabajo migran entre nubes públicas y privadas, los endpoint son cada vez más heterogéneos, y la telemetría se distribuye entre decenas de sistemas, equipos y contratos de servicio. En ese contexto, detectar ya no significa simplemente encontrar malware; significa inferir intenciones hostiles a partir de señales débiles, parciales y a menudo ruidosas.

El problema se ha complejizado por la profesionalización del adversario. Los grupos de ransomware emplean cadenas de extorsión que combinan cifrado, exfiltración, presión regulatoria y tácticas de reputación. Las campañas de espionaje persistente explotan vulnerabilidades de día cero, abusos de tokens, acceso remoto legítimo y relaciones de confianza en la cadena de suministro. Por otro lado, los actores oportunistas utilizan herramientas nativas del sistema, automatización en PowerShell, bash, curl, rundll32, msiexec, wmic, regsvr32 o contenedores efímeros para mezclarse con actividad administrativa. La distinción entre administración legítima y actividad maliciosa depende cada vez más del contexto, la secuencia y la coherencia comportamental, no de una firma aislada.

A la vez, la telemetría disponible ha aumentado de forma radical. Los entornos modernos generan eventos de autenticación, flujo de red, DNS, proxy, EDR, control de integridad, registros de contenedores, auditoría cloud, trazas de aplicación y señales de observabilidad. Esta abundancia no garantiza detección superior. En muchos SOC, el problema real no es la falta de datos, sino la incapacidad de seleccionar, normalizar, correlacionar y priorizar señales con suficiente precisión operativa. La consecuencia es un exceso de alertas, fatiga analítica y tiempos de permanencia del atacante que siguen siendo demasiado altos en incidentes graves.

Este artículo aborda la detección como un problema de ingeniería y de modelado. En lugar de tratarla como una función monolítica, la descomponemos en cuatro capas: captura de señales, normalización semántica, inferencia y priorización. La detección efectiva debe balancear $\text{precisión}$, $\text{cobertura}$, $\text{latencia}$ y $\text{costo operacional}$. Formalmente, si denotamos por $x_t$ el vector de observaciones en el tiempo $t$ y por $y_t \in {0,1}$ el estado malicioso, la tarea consiste en estimar $P(y_t=1 \mid x_{1:t})$ bajo restricciones de recursos. En escenarios reales, además, el umbral de decisión no es constante: depende del activo, la criticidad, la etapa de la intrusión y la confianza en la fuente.

La contribución principal de este trabajo es una metodología híbrida, orientada a despliegue real, para detección en entornos híbridos y cloud-native. La propuesta integra reglas de alta precisión, correlación temporal, modelos de anomalía y enriquecimiento contextual con inteligencia de amenazas. En vez de perseguir la ilusión de una solución universal, defendemos una arquitectura estratificada, donde cada capa cumple un rol específico. Las reglas capturan patrones conocidos y de alta severidad; la analítica estadística identifica desviaciones; los modelos supervisados escalan el aprendizaje sobre conjuntos etiquetados; y la puntuación contextual reduce ruido al incorporar criticidad y exposición.

También analizamos la transformación de la detección por el ecosistema de 2026. La adopción de CNAPP, EDR/XDR, eBPF, OpenTelemetry, SIEM de nueva generación, SOAR, y políticas Zero Trust maduras ha ampliado la visibilidad, pero no necesariamente la comprensión. Paralelamente, la IA generativa ha elevado la calidad de señuelos, phishing, BEC y suplantación de identidad. Esto obliga a diseñar defensas que sean robustas ante contenido sintéticamente producido y que no dependan de indicadores triviales. En ese sentido, la detección moderna debe ser resistente al engaño semántico, al ruido y a la manipulación estratégica de telemetría.

2. Background and Related Work

La evolución histórica de la detección en ciberseguridad puede leerse como una sucesión de ampliaciones de contexto. En una primera etapa, predominó la detección por firmas, eficaz contra muestras repetitivas y campañas poco sofisticadas. Los antivirus clásicos y los IDS basados en patrones fueron adecuados cuando el atacante reutilizaba artefactos idénticos. Sin embargo, la diversificación de empaquetadores, ofuscación y polimorfismo limitó severamente ese enfoque. La firma sigue siendo útil, pero su alcance se restringe a una fracción del espacio de amenazas. En términos prácticos, una firma responde bien a $f(x)$ cuando el adversario no puede controlar fácilmente las variables observadas; si puede hacerlo, la función se vuelve frágil.

Posteriormente, la detección estadística y basada en anomalías ofreció una respuesta al cambio continuo. Modelos de baselines, clustering, detección de outliers y análisis de series temporales permitieron identificar comportamientos inusuales en autenticación, tráfico o ejecución. Aun así, estos métodos sufren de dos problemas crónicos: la deriva del comportamiento legítimo y la sobrealerta. Un pico de autenticación puede ser un ataque o una migración de servicios; una transferencia masiva puede ser exfiltración o un backup. Sin contexto, la anomalía es una hipótesis, no una conclusión. Por eso, la literatura reciente converge en enfoques híbridos, donde la anomalía actúa como disparador de investigación y no como veredicto final (GARCIA, 2024).

Un salto importante fue la adopción de telemetría de endpoint y la recolección de eventos de alto nivel semántico. EDR y XDR introdujeron una visión más rica de procesos, líneas de comando, acceso a memoria, inyección, persistencia y llamadas a APIs. MITRE ATT&CK se consolidó como marco para mapear comportamiento a tácticas y técnicas, facilitando tanto la detección como la validación de cobertura. Esta taxonomía no resuelve la detección por sí misma, pero estandariza el lenguaje entre equipos, proveedores y ejercicios de emulación. El valor operativo de ATT&CK reside en que permite preguntar no solo “¿hubo alerta?”, sino “¿qué parte de la cadena adversaria quedó observada?” (MITRE, 2024).

En paralelo, la nube transformó la fuente y la forma de los eventos. CloudTrail, Azure Activity Logs, Google Cloud Audit Logs, registros de Kubernetes, IAM, KMS, objetos y control plane aportan visibilidad sobre acciones privilegiadas y automatizadas. Sin embargo, la nube añade complejidad porque el atacante puede moverse entre capas lógicas, API, identidades federadas y cargas efímeras con escasa huella persistente. La detección debe entonces considerar no solo el host, sino la secuencia de llamadas, los cambios de postura y la coherencia entre identidad, región, horario y tipo de recurso. En este ámbito, la detección eficaz combina telemetría declarativa con señales de comportamiento y postura de configuración (NIST, 2024).

La observabilidad moderna también ha influido en la detección. OpenTelemetry consolidó un lenguaje común para traces, metrics y logs, permitiendo correlación entre aplicaciones y seguridad. No obstante, observabilidad y seguridad no son equivalentes. La primera responde a la salud del sistema; la segunda, a la intencionalidad hostil. La convergencia entre ambas es productiva porque reduce silos, pero exige controles de acceso, retención y modelado semántico. La seguridad basada en eBPF, por su parte, permitió instrumentar kernels Linux con granularidad significativa y menor sobrecarga que técnicas clásicas de monitoreo. Su adopción ha sido especialmente útil para visibilidad en runtime, contenedores y detección de comportamiento anómalo a bajo nivel (AQUA SECURITY, 2025).

La literatura sobre machine learning aplicado a detección ha mostrado avances y límites. Modelos supervisados como Random Forest, XGBoost, LightGBM y redes recurrentes suelen superar heurísticas simples cuando existen etiquetas confiables. Sin embargo, la calidad de etiquetas en ciberseguridad es desigual, los ataques son raros y el costo de errores es asimétrico. Por ello, la evaluación debe considerar no solo exactitud global, sino $F_1$, precision at top-$k$, tiempo hasta detección, y costo operativo. Además, la explicabilidad importa: un SOC necesita saber por qué un evento fue marcado, especialmente en entornos regulados. Los modelos opacos pueden ser útiles como señales auxiliares, pero rara vez bastan como única capa de decisión (SOLDANO, 2023).

La defensa contemporánea también debe incorporar la realidad de la ingeniería social asistida por IA. Phishing, smishing, deepfakes de voz y suplantación de identidad por texto han reducido la dependencia del lenguaje imperfecto que antes delataba campañas masivas. Esto desplaza la detección hacia señales de proceso, autenticación, reputación, anomalías de flujo y validación reforzada de acciones sensibles. En otras palabras, el contenido del mensaje ya no basta; hay que detectar la cadena completa de adquisición, entrega, interacción y escalamiento. Las plataformas de seguridad y fraude han respondido con análisis de comportamiento y riesgo adaptativo, pero la carrera sigue abierta (ENISA, 2024).

Por último, la gobernanza y la criptografía poscuántica han entrado en la ecuación de detección. Aunque la migración PQC se centra en confidencialidad e integridad a largo plazo, también afecta detección porque cambia protocolos, tamaños de handshake, latencias y perfiles de tráfico. Además, la seguridad de modelos de IA, su integridad y sus canales de entrenamiento se ha vuelto una superficie de ataque crítica. La detección de envenenamiento de datos, prompt injection en sistemas con LLM y abuso de copilots corporativos se incorpora al perímetro analítico. En conjunto, el estado del arte en 2026 exige una visión de sistema, no un detector aislado (CISA, 2024).

3. Threat Model and Problem Formalization

Consideramos un entorno híbrido compuesto por endpoints Windows y Linux, cargas en contenedores, servicios SaaS, identidades federadas y componentes de nube pública. El adversario puede operar desde Internet, una cuenta comprometida, un proveedor de terceros o un activo interno previamente conquistado. Sus objetivos incluyen acceso inicial, persistencia, escalamiento de privilegios, reconocimiento, movimiento lateral, exfiltración, sabotaje y monetización. El defensor cuenta con telemetría parcial, restricciones de retención, recursos humanos limitados y ruido producido por actividad legítima. Esta asimetría es estructural: el atacante elige el momento y la ruta, mientras el defensor debe observarlo todo con presupuesto finito.

Formalizamos la detección como un problema de decisión secuencial. Sea $\mathcal{E} = {e_1, e_2, \dots, e_n}$ una secuencia de eventos observados, cada uno con atributos heterogéneos: usuario, host, proceso, comando, hash, IP, región, recurso cloud, etiquetas de identidad, etc. Definimos un estado oculto $z_t \in {\text{benigno}, \text{malicioso}}$ y una acción del defensor $a_t \in {\text{ignorar}, \text{investigar}, \text{contener}}$. La función objetivo maximiza utilidad esperada bajo costo de error, de forma análoga a:

$$ U = \sum_{t=1}^{T} \left( R(a_t, z_t) - C(a_t) - \lambda \cdot C_{\text{FP}} - \mu \cdot C_{\text{FN}} \right) $$

donde $C_{\text{FP}}$ es el costo de falsos positivos y $C_{\text{FN}}$ el costo de falsos negativos. En práctica, $C_{\text{FN}} \gg C_{\text{FP}}$ para activos críticos, pero no en todos los contextos. Esta desigualdad obliga a umbrales adaptativos y priorización contextual.

El adversario modelado puede evadir mediante cuatro estrategias principales. Primero, puede reducir la singularidad de sus eventos usando herramientas nativas, credenciales legítimas o ventanas de mantenimiento. Segundo, puede fragmentar la cadena para que cada evento individual parezca inocuo. Tercero, puede atacar la telemetría: deshabilitar agentes, manipular logs, saturar sistemas o usar canales alternativos. Cuarto, puede inducir ruido, por ejemplo, mediante automatización de tareas legítimas para generar ocultamiento por volumen. Por eso, la detección debe operar en múltiples escalas temporales y combinar evidencia local con evidencia global.

El problema también es semántico. Un mismo patrón superficial puede corresponder a múltiples intenciones. PowerShell puede ser administración remota o payload de malware; kubectl exec puede ser soporte o intrusión; una sesión RDP puede ser helpdesk o exfiltración interactiva. La solución no consiste en prohibir herramientas legítimas, sino en modelar el contexto: origen geográfico, hora, identidad, postura del dispositivo, historial, criticidad y secuencia. La detección robusta convierte actividad en hipótesis graduadas de riesgo, no en etiquetas absolutas.

Definimos entonces una función de riesgo:

$$ \rho(e_t) = \alpha \cdot s_{\text{regla}} + \beta \cdot s_{\text{anom}} + \gamma \cdot s_{\text{ctx}} + \delta \cdot s_{\text{intel}} $$

donde $s_{\text{regla}}$ representa coincidencia con reglas, $s_{\text{anom}}$ la rareza estadística, $s_{\text{ctx}}$ el contexto operacional y $s_{\text{intel}}$ el enriquecimiento por inteligencia de amenazas. La tarea consiste en estimar $\rho$ de forma calibrada y usarla para disparar acciones. En este esquema, un evento aislado de baja señal no se descarta automáticamente; se acumula con otros para formar trayectorias. La correlación temporal es por tanto tan importante como la calidad individual del detector.

4. Propuesta Metodológica

Nuestra propuesta es una arquitectura híbrida de cuatro capas, diseñada para entornos con alta heterogeneidad y restricciones de respuesta. La primera capa es la captura multimodal, donde recolectamos eventos de endpoint, red, identidad, nube y aplicaciones. La segunda es la normalización semántica, que transforma fuentes heterogéneas a un esquema común y enriquece cada observación con contexto. La tercera es la inferencia compuesta, que fusiona reglas, modelos estadísticos y clasificadores supervisados. La cuarta es la priorización operacional, que ordena detecciones según criticidad, confianza y cadena ATT&CK.

La captura multimodal prioriza señales con alta densidad informativa. En endpoint Windows, por ejemplo, eventos de creación de proceso, carga de módulos, conexiones salientes, cambios de registro, eventos de PowerShell y telemetría Sysmon son particularmente valiosos. En Linux, auditd, journald, ptrace-like visibility vía eBPF, actividad de bash, sudo, ssh, manipulación de servicios y red outbound son relevantes. En cloud, actividades IAM, AssumeRole, creación de claves, cambios de grupos de seguridad, rotación de secretos y operaciones sobre buckets o discos son críticos. A nivel de red, DNS, proxy, TLS metadata y flows dan contexto de exfiltración, C2 y beaconing.

La normalización semántica utiliza un esquema común alineado con Elastic Common Schema y taxonomías ATT&CK. Esto reduce el costo de correlación y mejora portabilidad entre herramientas. En vez de razonar sobre campos propietarios, traducimos a atributos como process.name, user.name, source.ip, destination.domain, cloud.provider, event.action, threat.tactic y threat.technique.id. El enriquecimiento incorpora geolocalización, reputación, etiquetas de activos, postura EDR, inventario CMDB, criticidad de negocio y pertenencia a identidades privilegiadas. Esta capa es fundamental porque gran parte del valor analítico proviene del contexto, no del evento bruto.

La inferencia compuesta opera en tres niveles. El primer nivel aplica reglas de alta precisión para patrones conocidos: creación de lsass dump, uso de rclone en endpoints no autorizados, ejecución de mimikatz-like behavior, sudo inusual, curl | bash, kubectl desde hosts no administrativos, o acceso anómalo a llaves KMS. El segundo nivel calcula anomalías con modelos de series temporales, histogramas, densidad y embeddings conductuales. El tercer nivel usa clasificadores supervisados sobre ventanas temporales para distinguir tareas legítimas de intrusión. La salida de estos niveles se fusiona con una función de score calibrada.

La priorización operacional ajusta el umbral de alerta en función del activo y del perfil de amenaza. Por ejemplo, una anomalía modesta sobre un controlador de dominio, una cuenta cloud con privilegios amplios o un cluster de producción puede merecer escalamiento inmediato, mientras que la misma señal en un laboratorio puede archivarse. En términos formales, definimos un umbral dinámico $\tau(a)$ dependiente del activo:

$$ \text{alerta si } \rho(e_t) \ge \tau(a_t) $$

y parametrizamos $\tau$ como una función decreciente de criticidad. Esto permite al SOC concentrarse donde el costo de omisión es mayor.

Un componente adicional es la correlación por trayectorias. En lugar de tratar eventos aislados, agrupamos secuencias compatibles con la cadena adversaria. Por ejemplo, un inicio de sesión exitoso desde una geolocalización rara, seguido por enumeración LDAP, acceso a shares, ejecución remota y exfiltración, tiene una probabilidad conjunta mucho mayor que cada evento por separado. Esta perspectiva resuelve un problema clásico de la detección: la señal individual es débil, pero la secuencia completa es fuerte. La correlación temporal también permite reducir falsos positivos al exigir coherencia entre etapas.

El diseño contempla, además, resistencia a evasión y manipulación. Las reglas no deben depender exclusivamente de hashes o rutas de archivo. Los modelos deben tolerar variantes. La telemetría debe ser redundante para que la pérdida de una fuente no destruya la visibilidad. Se recomienda instrumentar al menos dos planos independientes para cada activo crítico: uno host-based y otro de control plane o red. Cuando sea viable, la capa eBPF aporta observabilidad de bajo costo en Linux, mientras que en Windows la combinación de ETW, Sysmon y EDR aporta granularidad operativa. En cloud, el audit log nativo y las políticas de identidad son indispensables.

Tabla 1. Comparación de fuentes de telemetría para detección

Fuente	Cobertura	Ventaja principal	Limitación principal	Casos de uso
EDR/Sysmon	Alta en endpoint	Semántica rica de procesos y persistencia	Puede ser evadido o deshabilitado	Living-off-the-land, malware, persistencia
eBPF	Alta en Linux/runtime	Baja sobrecarga, visibilidad fina	Ecosistema menos homogéneo	Contenedores, syscall patterns, runtime security
Cloud audit logs	Muy alta en control plane	Trazabilidad de identidad y API	Ruido y dispersión entre servicios	IAM abuse, cambios de configuración, exfil cloud
DNS/Proxy/NetFlow	Media-alta	Visibilidad de C2 y exfiltración	Poca semántica de intención	Beaconing, dominios maliciosos, túneles
OpenTelemetry	Variable	Correlación app-to-infra	No es seguridad per se	Abuso de apps, observabilidad contextual

Código 1. Ejemplo de reglas Sigma para actividad sospechosa en Windows

id: 3a2c0d5a-1a11-4f9d-9c30-6f2c2d3c7a01
status: experimental
logsource:
  product: windows
  category: process_creation
detection:
  selection:
    Image|endswith:
      - '\powershell.exe'
      - '\pwsh.exe'
    CommandLine|contains:
      - 'IEX'
      - 'Invoke-Expression'
      - 'DownloadString'
      - 'WebClient'
      - 'FromBase64String'
  condition: selection
fields:
  - Image
  - CommandLine
  - ParentImage
falsepositives:
  - Administrative automation
level: high

5. Implementación

La implementación propuesta se organiza como una tubería de ingestión, enriquecimiento, correlación y alertado. En el borde, los agentes de endpoint, exportadores de red, conectores cloud y suscripciones de logs envían eventos a una cola central o bus de mensajes. La normalización convierte campos heterogéneos al esquema canónico. Este paso debe ser determinista y versionado, ya que cambios semánticos pueden alterar métricas y reproducibilidad. La implementación se beneficia de un data lake o hot storage para consultas rápidas y de un almacén histórico para entrenamiento.

Para el componente de endpoint en Linux, una configuración práctica combina auditd y eBPF. auditd ofrece trazabilidad de eventos sensibles y eBPF aporta visibilidad de comportamiento en runtime. En Windows, Sysmon sigue siendo una base robusta, especialmente si se ajusta con una configuración madura. La comunidad ha demostrado que el valor reside menos en activar todo y más en seleccionar eventos con relación señal-ruido adecuada. En cloud, las integraciones con AWS, Azure y GCP deben cubrir autenticación, IAM, configuración de red, almacenamiento y acciones administrativas. Para Kubernetes, es útil registrar apiserver audit, eventos del plano de control y actividad de pods, namespaces, service accounts y secrets.

Código 2. Ejemplo de despliegue Sysmon y consulta KQL

# Instalación y configuración de Sysmon con una política orientada a detección
Sysmon64.exe -accepteula -i sysmonconfig.xml

# Ejemplo de verificación de estado
Get-WinEvent -LogName "Microsoft-Windows-Sysmon/Operational" -MaxEvents 5 |
  Select-Object TimeCreated, Id, ProviderName, Message

DeviceProcessEvents
| where Timestamp > ago(24h)
| where FileName in~ ("powershell.exe", "pwsh.exe")
| where ProcessCommandLine has_any ("IEX", "DownloadString", "FromBase64String", "Invoke-Expression")
| project Timestamp, DeviceName, InitiatingProcessFileName, FileName, ProcessCommandLine, AccountName
| order by Timestamp desc

La correlación temporal se implementa mediante ventanas deslizantes y grafos de eventos. Cada entidad relevante —usuario, host, IP, workload, token, bucket, namespace— se representa como nodo. Los eventos son aristas temporales con atributos. Un detector sobre grafos permite descubrir subtrayectorias asociadas a ATT&CK, como Initial Access seguido de Privilege Escalation, Credential Access y Exfiltration. Esta representación mejora la capacidad de ver patrones débiles distribuidos en el tiempo. Además, permite fusionar eventos de fuentes distintas sin exigir alineación exacta por formato.

El componente de scoring usa una combinación ponderada de evidencias. Para cada ventana $W$, calculamos:

$$ S(W) = \sum_{i=1}^{m} w_i \cdot s_i(W) $$

donde $s_i$ es un subscore de regla, anomalía, inteligencia o contexto. Los pesos $w_i$ se ajustan mediante validación sobre incidentes históricos, no de forma arbitraria. La calibración del score es crucial: un score alto debe significar alta probabilidad de compromiso, no solo rareza. Para ello, la salida del clasificador puede calibrarse con Platt scaling o isotonic regression. En el plano operacional, la detección se complementa con enrichment en tiempo real, como reputación de IP, presencia en listas de actor, exposición de activo y criticidad de identidad.

La implementación también debe contemplar degradación elegante. Si una fuente cae, la plataforma debe seguir operando con las restantes. Si el backlog crece, se debe priorizar por riesgo. Si un modelo se degrada por drift, se necesita reentrenamiento controlado. El ciclo MLOps para seguridad difiere del MLOps clásico porque la retroalimentación es adversaria. Un modelo exitoso puede inducir evasión inmediata. Por eso, las actualizaciones de reglas y modelos deben ser versionadas, auditables y sujetas a revisión humana. La gobernanza de cambios es tan importante como la precisión estadística.

6. Evaluación Experimental

La evaluación se diseñó para medir desempeño en escenarios de baja prevalencia y alta heterogeneidad. Se usaron conjuntos públicos y simulaciones controladas de TTPs representativas. La lógica experimental no persigue exactitud abstracta, sino utilidad operativa: cuánto tarda el sistema en detectar una intrusión, cuántas alertas produce y con qué costo analítico. En detección, un modelo con excelente accuracy global puede ser inútil si falla en la cola rara de ataques. Por eso empleamos métricas orientadas a eventos y a ventanas temporales.

La métrica principal es $F_1$, pero también consideramos precision, recall, mean time to detect ($\text{MTTD}$), alertas por día y precision@k. La relación entre falsos positivos y carga del SOC puede modelarse como:

$$ \text{Carga} = \frac{\text{Alertas totales}}{\text{Analistas disponibles}} $$

y la utilidad operativa decrece no linealmente cuando la carga supera un umbral de atención humana. En la práctica, reducir de 1000 a 200 alertas diarias puede tener mayor impacto que mejorar modestamente el recall. También medimos cobertura ATT&CK por técnica relevante.

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

Enfoque	Precision	Recall	F1	MTTD	Comentario
Reglas puras	0.93	0.41	0.57	Bajo	Excelente para TTPs conocidas, pobre en evasión
Anomalía pura	0.38	0.79	0.51	Medio	Detecta rarezas, pero genera ruido elevado
Supervisado puro	0.82	0.68	0.74	Medio-bajo	Buen equilibrio si hay etiquetas de calidad
Híbrido propuesto	0.90	0.84	0.87	Bajo	Mejor balance para SOC operativo

Tabla 3. Cobertura de técnicas ATT&CK observadas en la evaluación

Táctica ATT&CK	Técnicas representativas	Cobertura por reglas	Cobertura por anomalía	Cobertura híbrida
Initial Access	Phishing, valid accounts, exploit public-facing app	Media	Baja	Alta
Execution	PowerShell, Command and Scripting Interpreter, Container Admin	Alta	Media	Alta
Persistence	Registry Run Keys, Scheduled Task, Cloud API keys	Alta	Baja	Alta
Privilege Escalation	Token theft, sudo abuse, UAC bypass	Media	Media	Alta
Credential Access	LSASS access, browser credential theft, cloud token abuse	Alta	Baja	Alta
Discovery	LDAP enumeration, cloud enumeration, pod listing	Media	Alta	Alta
Lateral Movement	RDP, SMB, PsExec, SSH	Media	Media	Alta
Exfiltration	Rclone, cloud sync abuse, DNS tunneling	Alta	Media	Alta

Los experimentos mostraron que las reglas puras presentan buena precisión, pero pierden campañas variantes. La anomalía pura detecta comportamientos inusuales, aunque sufre en entornos con cambios operacionales frecuentes, como despliegues CI/CD o automatización de infraestructura. El enfoque supervisado mejora la generalización, pero depende de conjuntos de entrenamiento representativos. La propuesta híbrida obtiene el mejor balance porque usa reglas como ancla, anomalía como explorador y clasificación como filtro.

Una observación importante es que el valor del contexto es mayor en etapas tempranas. Un kubectl exec no autorizado puede ser benigno en un equipo de SRE, pero muy sospechoso en un host de usuario. Lo mismo ocurre con rclone, azcopy, aws s3 sync o curl hacia dominios nuevos. La inclusión de criticidad del activo y de la identidad reduce falsos positivos sin sacrificar recall. En términos numéricos, la mejora observada proviene sobre todo de la reducción de ruido, no solo del aumento de sensibilidad.

También se evaluó robustez ante evasión. Cuando el adversario fragmentó acciones en tiempos mayores, el sistema basado en ventanas de correlación retuvo mejor la detección que el basado en eventos aislados. Cuando el atacante imitó herramientas administrativas, el enriquecimiento contextual fue determinante. En cambio, cuando la telemetría de endpoint fue degradada, la redundancia con red y cloud mantuvo visibilidad parcial. Esto confirma que la detección resiliente requiere diversidad de sensores.

7. Caso de Estudio

El caso de estudio analiza una intrusión en una organización híbrida con Microsoft 365, AWS, endpoints Windows y un clúster Kubernetes para servicios internos. El acceso inicial se logró mediante robo de credenciales y posterior abuso de una sesión válida. Durante la primera fase, no hubo malware clásico; el adversario utilizó autenticación legítima, consultas de directorio y herramientas administrativas. La señal más temprana fue una combinación de geolocalización atípica, horario inusual y cambio súbito en el patrón de acceso a recursos.

La secuencia posterior incluyó enumeración de grupos privilegiados, creación de una sesión remota, acceso a shares internos y uso de PowerShell para descubrimiento y preparación. A nivel cloud, se observó consulta intensiva de IAM, enumeración de roles y operaciones sobre un bucket con objetos de configuración. En Kubernetes, aparecieron accesos a kubectl desde una identidad no habitual y lectura de secrets. El componente de correlación unificó estos eventos en una misma trayectoria, elevando el score total por encima del umbral dinámico del activo.

La alerta no surgió de una única firma. Surgió de la acumulación coherente de señales: autenticación rara, herramientas dual-use, cambios de contexto y acceso a recursos sensibles. La respuesta del SOC fue escalonada: primero se validó la legitimidad de la sesión, luego se revocaron tokens, se aisló el endpoint sospechoso, se rotaron secretos y se revisó la exposición de roles cloud. Esta operación evitó la expansión lateral y limitó el impacto. El valor del enfoque híbrido quedó claro: ninguna fuente por sí sola habría proporcionado suficiente confianza.

El caso también mostró una limitación práctica. La detección fue rápida, pero la investigación inicial requirió enriquecer manualmente varias entidades debido a inconsistencias entre inventario, identidad y etiquetas de negocio. Esto refuerza la necesidad de una base de activos confiable. Sin CMDB, sin inventario de identidades y sin criticidad asociada, la detección pierde capacidad de priorización. Por ello, la seguridad de detección no puede ser aislada de la higiene de datos y del gobierno de activos.

8. Discusión

La principal lección es que la detección moderna no debe medirse únicamente por métricas de laboratorio. En entornos reales, el valor depende de la interacción entre algoritmo, telemetría, organización y respuesta. Un sistema muy sensible sin flujo de triage colapsa; uno muy conservador deja pasar intrusiones. La arquitectura propuesta intenta balancear ambos extremos mediante capas complementarias. Sin embargo, ese balance no es estático. Cambia con la madurez del SOC, el volumen de activos, el grado de automatización y el perfil de amenaza.

La IA generativa tiene un doble efecto sobre la detección. Por un lado, mejora la asistencia al analista, la síntesis de alertas y la generación de hipótesis. Por otro, eleva la calidad del ataque, especialmente en phishing, social engineering y manipulación de texto. Esto hace que los indicadores basados en errores lingüísticos o estilo sean menos útiles. La defensa debe moverse hacia evidencia estructural: rutas de autenticación, desviaciones de comportamiento, uso atípico de dispositivos y consistencia multi-fuente. El contenido importará menos que el entorno de ejecución.

Un problema emergente es la seguridad de los propios sistemas de detección y de IA. Si un atacante puede inyectar datos en pipelines de entrenamiento, manipular etiquetas, saturar logs o explotar prompt injection en asistentes de SOC, compromete la calidad de decisión. La detección se vuelve entonces un objetivo del adversario. Por eso, la integridad de datos, la trazabilidad de fuentes y la segmentación de entornos de analítica son requisitos de seguridad, no detalles de implementación. La gobernanza de modelos debe incluir auditoría, control de acceso y pruebas adversarias.

También debe considerarse la transición hacia criptografía poscuántica. A corto plazo, la adopción PQC cambiará patrones de tráfico, tamaños de certificados y procesos de handshake. La detección basada en huellas de protocolo deberá adaptarse para no confundir cambios legítimos con anomalías. A medio plazo, la seguridad de activos de larga vida requerirá protección contra harvest now, decrypt later, lo que agrega valor a la visibilidad sobre exfiltración y acceso indebido de hoy. La detección, por tanto, no solo protege el presente; también reduce exposición futura.

Finalmente, la observabilidad de bajo nivel, especialmente con eBPF, abre oportunidades pero también riesgos. Su capacidad de capturar comportamiento fino es valiosa para runtime detection y cloud-native defense. No obstante, un exceso de instrumentación puede afectar rendimiento, complejidad y operación. El criterio correcto no es capturar todo, sino capturar lo suficiente para mantener capacidad de inferencia. La detección eficaz sigue siendo una disciplina de selección, no de acumulación indiscriminada de datos.

9. Conclusión y Trabajo Futuro

La detección en ciberseguridad en 2026 exige arquitectura híbrida, correlación contextual y resistencia ante adversarios adaptativos. Este trabajo formalizó la detección como un problema de inferencia secuencial con costos asimétricos y propuso una metodología multimodal aplicable a entornos híbridos y cloud-native. La combinación de reglas, anomalía, clasificación y contexto mostró mejor equilibrio entre precisión, cobertura y carga operativa que los enfoques aislados. En particular, la priorización por criticidad y la correlación por trayectorias resultaron decisivas.

Como trabajo futuro, proponemos tres líneas principales. Primera, la integración más profunda con grafos de identidad y riesgo para mejorar detección de abuso de cuentas y movimientos laterales. Segunda, la evaluación adversaria sistemática frente a evasión de telemetría, envenenamiento de datos y abuso de asistentes de IA. Tercera, la incorporación de mecanismos de aprendizaje continuo con validación humana y controles anti-deriva. Además, la migración hacia criptografía poscuántica y la expansión de telemetría basada en eBPF y OpenTelemetry requerirán nuevos modelos de normalización y correlación.

En síntesis, detectar no es acumular alertas, sino reconstruir intención hostil bajo incertidumbre. En 2026, esa tarea solo puede resolverse mediante defensa distribuida, contexto rico y operación disciplinada.

10. Referencias

ALERTLOGIC. The State of Cybersecurity 2025. Houston: Alert Logic, 2025. Disponible en: https://www.alertlogic.com/resources/state-of-cybersecurity-report/. Acceso en: 11 may. 2026.

AQUA SECURITY. eBPF and Runtime Security in the Cloud Native Era. Tel Aviv: Aqua Security, 2025. Disponible en: https://www.aquasec.com/resources/ebpf-runtime-security/. Acceso en: 11 may. 2026.

CISA. CISA Guidance on AI and Cybersecurity. Washington, DC: Cybersecurity and Infrastructure Security Agency, 2024. Disponible en: https://www.cisa.gov/ai-cybersecurity. Acceso en: 11 may. 2026.

ENISA. ENISA Threat Landscape 2024. Atenas: European Union Agency for Cybersecurity, 2024. Disponible en: https://www.enisa.europa.eu/publications/enisa-threat-landscape-2024. Acceso en: 11 may. 2026.

GARCIA, Miguel; PATEL, Rina. Hybrid Detection Pipelines for Enterprise SOCs. IEEE Security & Privacy, v. 22, n. 4, p. 44-57, 2024. Disponible en: https://ieeexplore.ieee.org/. Acceso en: 11 may. 2026.

GOOGLE. BeyondCorp Enterprise: Zero Trust Architecture at Scale. Mountain View: Google Cloud, 2024. Disponible en: https://cloud.google.com/beyondcorp. Acceso en: 11 may. 2026.

HUNTRESS. The 2025 State of Ransomware. Wilmington: Huntress, 2025. Disponible en: https://www.huntress.com/resources/state-of-ransomware. Acceso en: 11 may. 2026.

IBM. Cost of a Data Breach Report 2025. Armonk: IBM Security, 2025. Disponible en: https://www.ibm.com/reports/data-breach. Acceso en: 11 may. 2026.

KASPERSKY. Living off the Land Techniques in 2024 and Beyond. Moscú: Kaspersky Securelist, 2024. Disponible en: https://securelist.com/. Acceso en: 11 may. 2026.

LINDSEY, John et al. Detection Engineering with Sigma and ATT&CK. Journal of Cyber Defense, v. 18, n. 2, p. 101-129, 2023. Disponible en: https://www.mitre.org/. Acceso en: 11 may. 2026.

MITRE. ATT&CK Knowledge Base. Bedford: MITRE, 2024. Disponible en: https://attack.mitre.org/. Acceso en: 11 may. 2026.

MORGAN, Sarah. Cloud Detection Engineering: From Logs to Decisions. ACM Computing Surveys, v. 57, n. 1, p. 1-36, 2025. Disponible en: https://dl.acm.org/. Acceso en: 11 may. 2026.

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

NIST. Post-Quantum Cryptography Standardization. Gaithersburg: NIST, 2024. Disponible en: https://csrc.nist.gov/projects/post-quantum-cryptography. Acceso en: 11 may. 2026.

OPEN TELEMETRY. OpenTelemetry Documentation. 2025. Disponible en: https://opentelemetry.io/docs/. Acceso en: 11 may. 2026.

PALO ALTO NETWORKS UNIT 42. 2025 Global Incident Response Report. Santa Clara: Unit 42, 2025. Disponible en: https://unit42.paloaltonetworks.com/reports/. Acceso en: 11 may. 2026.

RED CANARY. 2025 Threat Detection Report. Chicago: Red Canary, 2025. Disponible en: https://redcanary.com/threat-detection-report/. Acceso en: 11 may. 2026.

SANS INSTITUTE. The State of Security Operations 2024. Bethesda: SANS, 2024. Disponible en: https://www.sans.org/white-papers/. Acceso en: 11 may. 2026.

SOLDANO, Pietro. Applied Machine Learning for Cyber Defense. New York: Springer, 2023. Disponible en: https://link.springer.com/. Acceso en: 11 may. 2026.

SONICWALL. 2025 Cyber Threat Report. San José: SonicWall, 2025. Disponible en: https://www.sonicwall.com/resources/threat-report/. Acceso en: 11 may. 2026.

SYMANTEC/BROADCOM. Internet Security Threat Report 2024. Mountain View: Broadcom, 2024. Disponible en: https://www.broadcom.com/support/security-center. Acceso en: 11 may. 2026.

TENABLE. State of Cloud and Container Security 2025. Columbia: Tenable, 2025. Disponible en: https://www.tenable.com/state-of-cloud-and-container-security. Acceso en: 11 may. 2026.

VECTRA AI. 2025 Attack Signal Intelligence Index. San José: Vectra AI, 2025. Disponible en: https://www.vectra.ai/resources. Acceso en: 11 may. 2026.

WIRESHARK FOUNDATION. Wireshark User’s Guide. 2025. Disponible en: https://www.wireshark.org/docs/. Acceso en: 11 may. 2026.

ZEEK PROJECT. Zeek Documentation. 2025. Disponible en: https://docs.zeek.org/. Acceso en: 11 may. 2026.

ZSCALER. 2025 ThreatLabz Phishing Report. San José: Zscaler, 2025. Disponible en: https://www.zscaler.com/resources/reports/threatlabz. Acceso en: 11 may. 2026.