Cisco Foundation AI en operaciones de seguridad: cómo Deloitte Japón automatizó el SOC con modelos abiertos

Introducción

Los equipos de operaciones de seguridad (SOC) enfrentan un problema creciente: el volumen de alertas supera la capacidad de análisis humano. Según el 2024 Verizon Data Breach Investigations Report, el 50% de las alertas generadas por sistemas de detección (SIEM, EDR, IPS) son falsos positivos o de baja criticidad. Esto obliga a los analistas a perder hasta un 60% de su tiempo en tareas repetitivas como:

• Analizar logs crudos en formato no estructurado.
• Triar alertas manualmente para priorizar incidentes reales.
• Crear reglas de supresión o exclusión basadas en patrones específicos.

Deloitte Japón resolvió este desafío integrando el modelo Foundation-sec-1.1-8B-Instruct de Cisco Foundation AI en su flujo de trabajo del SOC. Este LLM de código abierto, especializado en seguridad, permitió automatizar tres flujos críticos:

1. Análisis de alertas con contexto enriquecido (asset enrichment, threat intelligence, historiales de casos).
2. Priorización de alertas mediante evaluación de severidad y detección de falsos positivos.
3. Generación de reglas de supresión basadas en casos confirmados de falsos positivos.

El resultado no fue reemplazar a los analistas, sino automatizar las tareas más repetitivas con un modelo pequeño (8 mil millones de parámetros) que, gracias a técnicas de prompt tuning y workflows, igualó el rendimiento de modelos con más de 120 mil millones de parámetros.

Qué ocurrió

En febrero de 2025, Deloitte Japón anunció la validación en producción de tres workflows basados en el modelo Foundation-sec-1.1-8B-Instruct de Cisco Foundation AI. Estos workflows se integraron directamente en el SOC de Deloitte Japón, un proveedor de servicios gestionados de seguridad (MSSP) que procesa miles de alertas diarias de clientes en Japón y Asia-Pacífico.

Los tres workflows implementados

1. Workflow de análisis de alertas

– Proceso:

– Ingesta de alertas: Extracción de campos clave (IP origen, usuario, regla activada, timestamp).

– Recolección de eventos relacionados: Consulta a fuentes como IPS (Cisco Firepower) y EDR (CrowdStrike, SentinelOne) en una ventana de ±1 hora alrededor del evento.

– Grounding con RAG: Búsqueda en runbooks internos, casos anteriores, notas de detección y threat intelligence (MISP, AlienVault OTX) para contextualizar la alerta.

– Enriquecimiento de activos: Consulta a CMDB (ServiceNow, BMC Helix) para obtener datos del asset afectado (sistema operativo, parches aplicados, criticidad).

– Evaluación de impacto: El modelo asigna un score de severidad (ej: Critical, High, Medium, Low) y genera un borrador de informe con:

– Razón del score.

– Evidencia clave (ej: «El proceso svchost.exe en el host W10-DEV-01 intentó conectarse a un IP en la lista negra de Cisco Talos»).

– Incertidumbre (ej: «No hay logs de EDR para este host en las últimas 24 horas»).

– Salida: Informe estructurado en JSON con traza auditable de cada paso. Ejemplo:

     {
       "alert_id": "QID-20250314-4567",
       "severity": "High",
       "rationale": "El tráfico a la IP 192.0.2.100 coincide con IOCs de ransomware conocido (SHA-256: abc...).",
       "evidence": ["IPS alerta ID 12345 en Firepower", "EDR detectó proceso `powershell.exe` ejecutando cmdlets sospechosos"],
       "next_steps": ["Bloquear IP 192.0.2.100 en firewall", "Investigar host W10-DEV-01"]
     }
     

1. Workflow de priorización y detección de falsos positivos

– Proceso:

– Recolección de eventos: El modelo consume no solo la alerta, sino también:

– Actividad de EDR en las ±2 horas previas (ej: procesos ejecutados, conexiones de red).

– Contexto del asset (ej: «Este host no tiene acceso a Internet según logs de proxy»).

– Evaluación de severidad: Usa un prompt específico que pregunta: «¿Esta alerta es un falso positivo dado el contexto del asset y la actividad reciente?».

– Generación de informe: Incluye un campo is_false_positive (booleano) y justificación. Ejemplo:

       {
         "alert_id": "CS-ALERT-89012",
         "is_false_positive": true,
         "rationale": "El proceso `msiexec.exe` fue ejecutado por `System` durante una tarea programada de Windows Update. No hay evidencia de ejecución de scripts maliciosos.",
         "suppression_suggestion": "Excluir alertas de CrowdStrike Falcon con regla_id=12345 cuando el proceso sea `msiexec.exe` y el usuario sea `System`"
       }
       

– Resultado: Reducción del 40% en tiempo de triage para alertas de baja criticidad.

1. Workflow de generación de reglas de supresión

– Proceso:

– Extracción de entidades: El modelo identifica campos clave en el ticket (ej: process_name, user, command_line, ip_destination).

– Selección de condiciones: En lugar de generar la regla directamente, el modelo elige condiciones predefinidas (ej: «process_name == powershell.exe AND command_line CONTAINS EncodedCommand«).

– Ensamblaje de la regla: Combina las condiciones en formato nativo del SIEM (ej: para Splunk):

       index=windows sourcetype=XmlWinEventLog:Microsoft-Windows-Sysmon/Operational
       (process_name="powershell.exe" AND command_line="*EncodedCommand*")
       | eval is_false_positive=1
       | table _time, host, user, process_name, is_false_positive
       

– Validación: El analista revisa la regla antes de implementarla. En pruebas piloto, el 85% de las reglas generadas eran válidas sin modificación.

Impacto para Seguridad

El modelo Foundation-sec-1.1-8B-Instruct no es un reemplazo de los analistas, sino un multiplicador de productividad. Los datos reportados por Deloitte Japón muestran:

1. Costos de inferencia:

– Foundation-sec-1.1-8B-Instruct puede ejecutarse en CPU-only con optimizaciones (ej: GGUF + llama.cpp) en un servidor con 32GB RAM (ej: AWS EC2 c6i.2xlarge, ~$0.50/hora).

1. Sesgo en modelos grandes:

1. Compliance y auditoría:

– Cada salida incluye un campo uncertainty_drivers que enumera limitaciones (ej: «No hay logs de EDR para este host en las últimas 24 horas»), crucial para informes regulatorios.

Detalles técnicos

Arquitectura de los workflows

Los tres workflows se implementaron usando:

• Cisco Foundation AI: Modelo Foundation-sec-1.1-8B-Instruct (versión 1.1, released en enero 2025).

– Contexto máximo: 8K tokens (suficiente para alertas complejas).

– Entrenamiento: Dataset de 1.2 millones de alertas etiquetadas por analistas de Cisco Talos.

– Evaluación: Precisión del 92% en detección de falsos positivos (vs. 85% del modelo Llama-2-7B en pruebas internas).

• Orquestación:

– Helm charts para desplegar los agentes en Kubernetes. Ejemplo de values.yaml para un agente de análisis de alertas:

    agent:
      name: "soc-alert-analyzer"
      model:
        name: "foundation-sec-1.1-8B-Instruct"
        provider: "cisco-foundation-ai"
        gpu: false  # Ejecución en CPU con GGUF
      rag:
        sources:
          - "misp://your-misp-instance"
          - "threat-intel://cisco-talos"
          - "runbooks://documents/soc/runbooks"
      outputs:
        format: "json"
        storage:
          s3:
            bucket: "soc-reports"
            region: "ap-northeast-1"
    

– Prompts específicos: Cada workflow usa un prompt template distinto. Ejemplo para priorización de alertas (en formato Jinja2):

    {% set alert = alert_data %}
    {% set asset = asset_enrichment %}
    {% set evidence = edr_telemetry %}

    Eres un analista de SOC. Analiza la siguiente alerta y responde en formato JSON:

    {
      "severity": "High/Medium/Low/Informational",
      "is_false_positive": true/false,
      "rationale": "Explica en 1-2 oraciones por qué la alerta es un falso positivo o no.",
      "next_steps": ["Acción 1", "Acción 2"],
      "uncertainty_drivers": ["Limitación 1", "Limitación 2"]
    }

    Datos de la alerta:
    - Regla: {{ alert.rule_name }}
    - Host: {{ asset.hostname }} (OS: {{ asset.os }}, Criticidad: {{ asset.criticality }})
    - Evidencia EDR: {{ evidence | join(', ') }}
    

Requisitos de hardware

1. SIEM: Splunk (modo HTTP Event Collector), IBM QRadar (API REST), Microsoft Sentinel (Log Analytics).
2. EDR/IPS: CrowdStrike Falcon (API v2), Cisco Secure Firewall (FMC API), SentinelOne (API v2.1).
3. CMDB: ServiceNow (REST API), BMC Helix (GraphQL).
4. Threat Intelligence: MISP (REST API), AlienVault OTX (CSV via S3), Cisco Talos (STIX/TAXII).

Qué deberían hacer los administradores y equipos técnicos

1. Evaluar si Foundation-sec-1.1-8B-Instruct aplica a tu entorno

• ¿Tu SOC procesa más de 500 alertas diarias?
• ¿Tienes runbooks, casos históricos o threat intelligence estructurados?
• ¿Quieres reducir falsos positivos en un 30% o más?

Si respondiste «sí» a al menos dos, sigue estos pasos:

Paso 1: Probar el modelo en un entorno aislado

# Clonar el repositorio de Cisco Foundation AI
git clone https://github.com/cisco-open/foundation-ai-models.git
cd foundation-ai-models/models/Foundation-sec-1.1-8B-Instruct

# Convertir el modelo a GGUF (para CPU)
pip install -U transformers==4.40.0
pip install -U llama-cpp-python==0.2.7
python convert_to_gguf.py --model-name foundation-sec-1.1-8B-Instruct --output-dir ./gguf

# Desplegar con Docker (usando GPU si está disponible)
docker run -d \
  --name foundation-sec-ai \
  -p 8000:8000 \
  -v $(pwd)/gguf:/models \
  -e MODEL_PATH=/models/Foundation-sec-1.1-8B-Instruct.gguf \
  -e MAX_TOKENS=8192 \
  ghcr.io/cisco-open/foundation-ai-api:latest

Paso 2: Implementar un workflow de prueba (ej: análisis de alertas)

1. Conecta el modelo a tu SIEM:

– Ejemplo de payload para Splunk:

     {
       "alert": {
         "id": "SPL-12345",
         "rule": "Suspicious PowerShell Command",
         "src_ip": "203.0.113.10",
         "user": "DOMAIN\\jdoe",
         "timestamp": "2025-03-14T14:30:00Z"
       },
       "context": {
         "asset": {
           "hostname": "W10-DEV-01",
           "os": "Windows 10",
           "criticality": "Medium"
         },
         "edr_telemetry": [
           {"process": "powershell.exe", "cmdline": "powershell -EncodedCommand ...", "time": "2025-03-14T14:28:00Z"}
         ]
       }
     }
     

1. Valida las salidas:

– Usa métricas como precisión, recall y F1-score para comparar con tus analistas humanos.

Paso 3: Escalar con Helm y Kubernetes

# Instalar Helm (si no está instalado)
curl https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3 | bash

# Añadir repositorio de Cisco Foundation AI
helm repo add cisco-foundation-ai https://cisco.github.io/helm-charts/
helm repo update

# Desplegar el agente de análisis de alertas
helm install soc-alert-analyzer cisco-foundation-ai/soc-agent \
  --namespace security \
  --create-namespace \
  --set agent.model.name="foundation-sec-1.1-8B-Instruct" \
  --set agent.rag.sources[0].name="misp" \
  --set agent.rag.sources[0].url="https://misp.your-org.com" \
  --set agent.outputs.storage.s3.bucket="soc-reports"

2. Implementar workflows de producción

3. Optimizar y mantener

1. Actualiza el modelo:

– Usa un pipeline de CI/CD para actualizar automáticamente:

     # Ejemplo con ArgoCD
     kubectl apply -f argocd-app.yaml
     

1. Ajusta los prompts:

– Ejemplo de ajuste para alertas de Living off the Land:

     {% if "powershell" in alert.command_line and "EncodedCommand" in alert.command_line %}
       severity: "High"
       is_false_positive: false
       rationale: "Comando PowerShell con EncodedCommand es común en ataques pero requiere contexto adicional."
     {% endif %}
     

1. Monitorea el rendimiento:

– Latencia por prompt (debe ser <5s por alerta).

– Tasa de aceptación por analistas (ej: 80% de los informes generados son aceptados sin modificación).

Conclusión

Deloitte Japón demostró que no se necesita un modelo enorme para automatizar tareas críticas en un SOC. Foundation-sec-1.1-8B-Instruct, con sus 8 mil millones de parámetros, igualó el rendimiento de modelos 15 veces más grandes gracias a:

• Workflows diseñados por analistas (no prompts genéricos).
• RAG con contexto específico (runbooks, casos históricos, threat intelligence).
• Salidas estructuradas (JSON con traza auditable).

Para equipos de Seguridad, Infraestructura o DevOps que buscan reducción de costos sin sacrificar precisión, este caso es un playbook reproducible. Los pasos clave son:

1. Probar el modelo en un entorno aislado con alertas reales.
2. Implementar workflows por etapas (empieza con priorización de alertas).
3. Optimizar prompts y RAG basados en feedback de analistas.

El futuro de los SOC no es reemplazar humanos con IA, sino darles herramientas para enfocarse en lo que realmente importa: investigar incidentes complejos y mejorar las defensas proactivamente.

Fuentes—

https://blogs.cisco.com/ai/deloitte-japan-advances-security-operations-with-cisco-foundation-ai-open-source-model

Blog

https://www.kali.org/blog/