Auditoría y respuesta: detección temprana con agentes IA

La ventana que importa: los primeros 20 minutos

En un incidente de seguridad, el daño crece exponencialmente durante los primeros minutos y luego se estabiliza. Un ransomware encriptando archivos en los primeros 10 minutos compromete 5% de datos; en 60 minutos, 80%. Un atacante exfiltrando datos necesita unas decenas de requests para vaciar una tabla de usuarios; si detectas el patrón al tercero, perdiste 3 registros, si lo detectas al minuto 15 perdiste 80.000.

Eso convierte a la detección temprana en el KPI maestro de toda operación de seguridad. Y ese es precisamente el territorio donde los agentes IA aportan valor real — no como marketing, sino porque la correlación de señales multidimensionales es el tipo de tarea para la que los modelos modernos están hechos.

Este artículo describe cómo construir una capa de auditoría con agentes IA que reduzca detección y respuesta — sin las trampas típicas (alertas ruidosas, automatismos que rompen la operación, agentes que se saltan el humano cuando no deberían).

Qué es "auditoría activa" vs "log archivístico"

Primera distinción clave:

• Log archivístico = guardas eventos para que alguien los lea después. Útil para forense, inútil para detección temprana.
• Auditoría activa = los eventos pasan por un pipeline que los correlaciona y dispara acciones. El log queda, pero el valor está en lo que pasa en tiempo real.

Los agentes IA tienen sentido en la segunda categoría. Para archivo, un SIEM clásico sobra. Para activa, donde el valor está en correlacionar señales heterogéneas bajo presión de tiempo, la capa de razonamiento inductivo de un LLM bien diseñado aporta.

Las cuatro capas de detección que Drokio opera

Capa 1: reglas determinísticas (lo primero que dispara)

Patrones conocidos, rápidos, baratos. Ejemplos:

• Más de 20 intentos de login fallido desde la misma IP en 60 segundos.
• Ejecución de PHP en /wp-content/uploads/.
• Creación de usuario con rol administrator fuera de horario de trabajo.
• Request con payload que contiene UNION SELECT + patrones de encoding.

Estas reglas son deterministas, explicables, y cubren 80-90% del volumen de detección. Son el baseline. Un agente IA no reemplaza esta capa; opera encima.

Capa 2: baseline + anomalías estadísticas

Modelos clásicos de anomaly detection: media móvil y desviación estándar por métrica, clustering de requests por similitud, z-score para saltos. Detectan:

• Incrementos anómalos de tráfico hacia un endpoint específico.
• Picos de uso de una tool de agente IA por encima del percentil 99 habitual.
• Volumen inusual de retrievals de la KB por un usuario.
• Escritura anormal en tablas específicas de la base de datos.

La capa 2 produce false positives regularmente — es inherente. La gran mayoría se descartan automáticamente con contexto de capa 3.

Capa 3: correlación con contexto (aquí entra el agente IA)

Un agente IA recibe el evento anómalo, el contexto temporal (qué pasó en los últimos 15 minutos), contexto organizacional (quién es el usuario, qué permisos tiene, qué hacía normalmente), y decide:

• ¿Esto es un incidente real, un false positive, o algo que necesita revisión humana?
• ¿Qué otras señales debería revisar para confirmar?
• ¿Qué acción inicial corresponde (bloquear, alertar, escalar)?

El agente no inventa: tiene acceso a un corpus curado de playbooks y precedentes. Si reconoce el patrón, actúa; si no, escala con contexto preparado.

Capa 4: humano en el loop para decisiones irreversibles

Ninguna acción irreversible (pausar sistemas productivos de cliente, borrar datos, notificar a terceros) se toma sin humano. El agente prepara el paquete: evidencia, hipótesis, acciones recomendadas, impacto estimado. El humano aprueba, modifica o rechaza.

Esta arquitectura es lo que diferencia a la auditoría con IA usable en producción del entusiasmo de 2023 que prometía "AI SOC autónomo". El AI SOC autónomo no funciona porque el error de cola de un LLM es catastrófico en contextos donde el costo de false positive es alto (pausar el sistema de un cliente grande por 4 horas por una hipótesis incorrecta).

Respuesta automatizada: qué conviene automatizar

Principio: automatiza lo reversible, ata al humano lo irreversible.

Automatizable sin pestañear:

• Bloqueo de IP por 1 hora (auto-desbloqueo si no se repite).
• Rate-limiting adicional a un usuario sospechoso.
• Marcado de sesión como "requiere re-autenticación".
• Quarantine de archivo subido sospechoso.
• Pausa de envío de mensajes salientes en un canal hasta revisión.

Requiere aprobación humana:

• Bloqueo de usuario/cuenta.
• Pausa de un squad completo (use el kill-switch).
• Notificación externa (clientes, proveedor, autoridad).
• Modificaciones destructivas (borrado de registros, rollback de base de datos).
• Cualquier acción que afecte clientes finales directamente.

Cómo medir si la detección mejora

KPIs que usamos en reviews:

• MTTD: minutos entre primera señal y detección confirmada.
• MTTC: minutos entre detección y contención inicial.
• MTTR: horas/días entre contención y recuperación completa.
• False positive rate por categoría: si sube, algo se desalineó.
• Detections sin clasificación humana: cola de investigación. Si crece, el equipo está sobrepasado.
• Detecciones que llevaron a cambio de política: señal de aprendizaje real.

El KPI anti-vanidad: "¿cuántos incidentes se detectaron por señal automática vs por reporte externo (cliente, partner)?". Si los incidentes críticos te los avisa un cliente antes que tu sistema, el sistema no está funcionando.

Playbooks: el activo que más rinde

Los agentes IA son tan buenos como los playbooks que consumen. Un agente sin playbooks improvisa; un agente con playbooks detallados ejecuta consistentemente.

Playbooks críticos que mantenemos:

1. Credential stuffing detectado: pasos inmediatos (rate-limit, MFA forzada, notificación a admin).
2. Webshell detectado: cuarentena, snapshot, escalación a humano, hipótesis de origen.
3. Exfiltración anómala de datos: medición de scope, preservación de evidencia, bloqueo de acceso.
4. Prompt injection en un squad: registro del turn, ajuste de guardrails, análisis de blast radius.
5. Defacement / integrity violation: revert desde backup verificado, audit de permisos, investigación de origen.
6. Zero-day en dependencia crítica: mitigación temporal, coordinación con proveedor, rollout de parche.

Cada playbook tiene dueño, versión, fecha de último drill, y métrica de tiempo medio de ejecución. Playbook sin drill no es playbook, es teoría.

Drills y red team: entrenar el sistema

El sistema que nunca fue probado es como un extintor comprado en 2015 y nunca recargado. El valor real se mide en el día del incendio.

Cadencia recomendada:

• Drill de escritorio mensual: equipo sobre la mesa, se simula un incidente, se sigue el playbook hasta el final. Se cronometran pasos.
• Drill técnico trimestral: incidente inyectado en ambiente real (con coordinación). Se mide MTTD real, no simulado.
• Red team externo semestral: empresa externa con scope controlado intenta comprometer sistemas. Findings quedan documentados y se priorizan.
• Post-mortem público trimestral: incidentes del trimestre, qué se aprendió, cambios aplicados. Transparencia interna y externa cuando corresponde.

Lo que NO hacer

No automatices notificaciones externas. El costo de enviar un "incidente de seguridad" por error a un cliente grande es reputacional y contractual. Humano siempre.

No silencies alertas con 40% de FPR "porque molestan". Hay que afinarlas, no apagarlas. Si realmente no mejoran, se retira la regla.

No mezcles detección de seguridad con monitoreo de producto. Son pipelines distintos con sensibilidades distintas. Mezclarlas produce fatiga.

No dejes el agente sin supervisión en producción los primeros 30 días. Humano revisa cada decisión y el agente aprende de las correcciones.

El ciclo de detección y respuesta con agentes IA

La arquitectura que funciona en operación se divide en tres bucles anidados, cada uno con cadencia y tolerancia de error propia:

Bucle rápido (segundos a minutos). Agente analiza logs streaming, detecta patrones conocidos de ataque (fuerza bruta, exfiltración de datos, escalada de privilegios), dispara alertas o acciones automáticas de contención (bloqueo de IP, revocación de token, kill session).

Bucle medio (minutos a horas). Agente correlaciona eventos entre fuentes (EDR + firewall + IAM + DNS + correo), construye narrativa del incidente, propone hipótesis de causa raíz, recomienda acciones. El humano analista toma la decisión final sobre acciones no reversibles (resetear ambiente, llamar forense, notificar compliance).

Bucle lento (horas a días). Agente hace post-mortem asistido: reconstruye timeline completo, identifica gaps de detección, propone mejoras de reglas o políticas. El output va a review humano antes de aplicar.

Cada bucle tiene su propio set de métricas. El rápido se mide en MTTD (mean time to detect), el medio en MTTR (mean time to respond), el lento en tiempo-a-lesson-learned. Optimizar uno sin mirar los otros desbalancea el sistema.

Qué evitar al adoptar agentes IA en SOC

Vemos tres fallos repetidos:

Fallo 1: reemplazar al analista. El agente es acelerador, no sustituto. Los analistas aportan contexto de negocio, criterio político, y responsabilidad legal que el agente no puede tomar. Reemplazarlos crea riesgo operativo y legal.

Fallo 2: confiar en acciones automáticas sin revisión. Un agente que bloquea IPs automáticamente sin contexto puede tirar servicios críticos (CDN, proveedor cloud, partner). Acciones automáticas deben limitarse a casos con altísima confianza y bajo impacto.

Fallo 3: no loguear las decisiones del agente. Cada decisión debe quedar en audit log con razón, evidencia y nivel de confianza. Sin esto, al primer incidente post-agente no hay cómo auditar si el agente falló o si el analista lo obedeció ciegamente.

Cómo se integra con herramientas existentes

Los SOCs reales tienen stack fragmentado: SIEM, EDR, NDR, XDR, SOAR, ticketing. El agente debe operar como orquestador, no como reemplazo:

• Entrada: consume logs de SIEM (Splunk, Sentinel, Elastic, Chronicle), alertas de EDR (CrowdStrike, SentinelOne, Defender), señales de NDR (Darktrace, Vectra), contexto de IAM.
• Enriquecimiento: consulta threat intel (VirusTotal, AbuseIPDB, internal TIP), asset inventory, usuarios/roles.
• Acción: vía SOAR existente (XSOAR, Tines, Torq) o integraciones directas. Las acciones quedan firmadas al agente, no al SOAR.
• Output: tickets enriquecidos en el sistema del SOC (ServiceNow, Jira), reportes diarios a CISO, kpis a dashboard ejecutivo.

El agente se suma al stack. No lo reemplaza. Empresas que intentan "reemplazar el SIEM con un agente IA" están construyendo castillo de cartas.

Preguntas frecuentes

¿El agente IA ve todos mis datos?

No. Solo metadata y eventos relevantes para detección. El contenido real (archivos, mensajes, docs) se mantiene en su lugar y se accede con permiso explícito cuando un humano lo autoriza.

¿Qué pasa si el agente equivoca la clasificación?

Si es false positive, el humano lo corrige y la señal entra en la base de aprendizaje. Si es false negative (no detectó algo que debía), es un incidente — se analiza post-mortem y se agrega regla/contexto que lo habría evitado.

¿Puedo integrar con mi SIEM (Splunk, Elastic, Wazuh)?

Sí. Drokio exporta eventos en formato compatible con Syslog y CEF. El SIEM sigue siendo la fuente primaria si ya lo tienes; Drokio actúa como capa de enriquecimiento y respuesta.

¿Tiempo de onboarding?

Típicamente 2-4 semanas: primera semana en modo observación para baseline, siguientes semanas activando políticas gradualmente. Un entorno complejo puede extenderse a 6 semanas.

¿Certificación SOC 2 / ISO 27001?

No "certificamos" al cliente. Drokio genera la evidencia auditable que esas certificaciones exigen (controles activos, incidentes, MTTD). La certificación la emite el auditor externo.

¿Funciona fuera de horas laborales?

Sí. 24/7. Los planes Enterprise incluyen guardia humana 24/7; Pro incluye respuesta en horario extendido.

¿Cómo se compara con contratar un MSSP?

Complementario. Un MSSP aporta recurso humano; Drokio aporta plataforma. Muchos clientes usan ambos: MSSP opera con Drokio como cockpit.

¿Qué pasa en incidentes graves: respondemos juntos o solos?

Depende del plan. Enterprise incluye respuesta conjunta con equipo humano Drokio en < 30 minutos. Pro incluye soporte de expertos en horario extendido. Starter es autosvcio con documentación y acceso a comunidad. En todos los casos el cliente mantiene control total; Drokio asiste, no reemplaza decisión final.

¿Integración con threat intel premium (Recorded Future, Mandiant)?

Disponible como add-on. Los feeds se consumen vía conectores nativos y enriquecen alertas. No son requisito — open-source threat intel (AlienVault OTX, MISP community) cubre mucho terreno a costo cero.

Si tu operación de seguridad depende de alertas dispersas y tiempo de respuesta no medido, empezá con un diagnóstico de 10 minutos — evaluamos MTTD/MTTC actual y proponemos mejora. Para contexto mayor: Seguridad moderna: del plugin a la plataforma, ficha del producto en /products/drokio, sitio propio drokio.com.