Threat Detection Engineering & MITRE ATT&CK

01. ¿Qué es realmente Detection Engineering?

Detection Engineering es la disciplina encargada de diseñar, desarrollar, probar, desplegar y mantener mecanismos capaces de identificar actividad potencialmente maliciosa.

No consiste simplemente en escribir reglas.

Una detección profesional necesita responder a preguntas como:

• ¿Qué comportamiento queremos detectar?
• ¿Qué evidencias permiten identificarlo?
• ¿Dónde podemos observar esas evidencias?
• ¿Qué nivel de confianza tiene la detección?
• ¿Qué falsos positivos podemos esperar?
• ¿Cómo probamos que realmente funciona?
• ¿Qué hacemos cuando se activa?

02. La evolución de una detección

03. MITRE ATT&CK como lenguaje común

MITRE ATT&CK permite representar las técnicas y tácticas utilizadas por los atacantes.

Esto resulta especialmente importante para nuestro sistema porque nos proporciona un lenguaje común entre:

• Detection Engineering
• SOC
• Threat Intelligence
• Incident Response
• Red Team
• Blue Team
• AI Analyst

Observed behavior:
PowerShell execution

Potential technique:
T1059.001 - PowerShell

Confidence:
0.89

Evidence:
powershell.exe
encoded command
network connection
        

04. Tácticas, técnicas y procedimientos

05. De la técnica ATT&CK a una detección

Supongamos que queremos detectar PowerShell utilizado de forma sospechosa.

No debemos comenzar escribiendo inmediatamente una regla.

Primero debemos definir la hipótesis.

Observables

• powershell.exe
• EncodedCommand
• DownloadString
• Invoke-WebRequest
• conexiones de red
• ejecución desde procesos sospechosos

06. Una detección no debe depender de una única señal

Detectar simplemente:

process = powershell.exe

produciría una cantidad enorme de falsos positivos.

Debemos aumentar el contexto.

powershell.exe

AND

encoded command

AND

network connection

AND

parent process = suspicious.exe

07. Precision vs Recall

Una de las decisiones fundamentales en Detection Engineering consiste en equilibrar precisión y cobertura.

08. False Positives

Un falso positivo aparece cuando una detección se activa pero el comportamiento no representa una amenaza real.

Ejemplo:

powershell.exe
    +
Invoke-WebRequest

Puede ser:

• Ataque
• Script administrativo
• Herramienta de monitorización
• Software corporativo
• Automatización legítima

La solución no siempre consiste en eliminar la detección.

Podemos enriquecerla con contexto.

09. Detection as Code

Una arquitectura madura trata las detecciones como código.

Esto permite utilizar:

• Git
• Pull Requests
• Code Review
• CI/CD
• Automated Testing
• Versioning

10. Sigma Rules

Sigma permite representar detecciones de manera independiente del SIEM concreto.

title: Suspicious PowerShell Encoded Command

id: example-001

status: experimental

description:
  Detects PowerShell execution
  using encoded commands.

logsource:
  product: windows
  category: process_creation

detection:

  selection:
    Image|endswith:
      - '\powershell.exe'

    CommandLine|contains:
      - '-enc'
      - '-encodedcommand'

  condition:
    selection

level: high

tags:
  - attack.execution
  - attack.t1059.001

El alumno debe comprender que una regla no es simplemente una consulta. Es un artefacto de ingeniería.

11. Testing de detecciones

Una detección que nunca ha sido probada no debería considerarse fiable.

Debemos probar al menos:

12. La IA como Detection Engineer

Aquí aparece una aplicación extremadamente potente de IA.

Podemos utilizar un LLM para ayudarnos a generar detecciones a partir de una hipótesis de amenaza.

Ejemplo de prompt:

You are a senior Detection Engineer.

Create a Sigma detection for:

Technique:
T1059.001 PowerShell

Objective:
Detect suspicious PowerShell execution.

Requirements:

- Minimize false positives.
- Explain the detection logic.
- Identify required telemetry.
- Map to MITRE ATT&CK.
- Provide positive test cases.
- Provide negative test cases.
- Identify blind spots.
- Do not invent log fields.

13. El gran error: dejar que la IA invente telemetría

Por ejemplo, podría inventar:

process.integrity_level
endpoint.behavior_score
user.risk_level
process.network_reputation

Estos campos podrían no existir.

Por eso debemos proporcionar al modelo el esquema real de nuestra plataforma.

14. Detection Context Schema

Nuestro AI Detection Engineer debe conocer qué datos existen.

{
  "event_schema": {

    "timestamp": "datetime",

    "host": {
      "hostname": "string",
      "ip": "string",
      "os": "string"
    },

    "user": {
      "username": "string",
      "domain": "string"
    },

    "process": {
      "name": "string",
      "path": "string",
      "command_line": "string",
      "parent": "string"
    },

    "network": {
      "src_ip": "string",
      "dst_ip": "string",
      "dst_port": "integer"
    }

  }
}

A partir de este esquema, la IA puede generar detecciones realistas.

15. Detection Pipeline

16. Detection Lifecycle

17. Detection Coverage

Una organización no debería medir únicamente cuántas reglas tiene.

Debe medir qué técnicas es capaz de detectar.

18. Attack Path Detection

Las mejores detecciones no siempre analizan eventos aislados.

Analizan cadenas.

Initial Access
      │
      ▼
Valid Account
      │
      ▼
PowerShell
      │
      ▼
Discovery
      │
      ▼
Credential Access
      │
      ▼
Lateral Movement
      │
      ▼
Data Access

Nuestro sistema debería ser capaz de reconocer progresivamente estas secuencias.

19. Attack Graph

Podemos representar un ataque como un grafo.

Esta estructura será especialmente importante cuando evolucionemos nuestro AI SOC Analyst hacia un verdadero motor de razonamiento sobre ataques.

20. Laboratorio principal

21. Paso 1 — Definir la hipótesis

22. Paso 2 — Identificar telemetría

Necesitamos saber qué datos están disponibles.

Process Creation

Image
CommandLine
ParentImage
User
Hostname
Timestamp
ProcessId

Network Connection

SourceIP
DestinationIP
DestinationPort
ProcessId
Timestamp

23. Paso 3 — Diseñar la detección

PowerShell
    +
Encoded Command
    +
Network Connection
    =
High Confidence Detection

Ahora debemos decidir cómo relacionar los eventos.

Una posibilidad:

same host
AND
same process
AND
time window < 5 minutes

24. Paso 4 — Crear la regla

title: Suspicious Encoded PowerShell Network Activity

logsource:
  product: windows
  category: process_creation

detection:

  powershell:
    Image|endswith:
      - '\powershell.exe'

  encoded:
    CommandLine|contains:
      - '-enc'
      - '-encodedcommand'

  condition:
    powershell and encoded

level: high

tags:
  - attack.execution
  - attack.t1059.001

Esta sería solamente la primera versión.

25. Paso 5 — Enriquecimiento con IA

Una vez generada la alerta podemos utilizar el AI SOC Analyst.

ALERT

PowerShell
+
Encoded command
+
External connection

        ↓

AI ANALYSIS

- User context
- Host context
- Historical behavior
- IP reputation
- Threat intelligence
- MITRE mapping
- Previous incidents

        ↓

RISK

92 / 100

26. Ejemplo de análisis generado por IA

{
  "classification": "malicious_likely",

  "severity": "high",

  "risk_score": 92,

  "confidence": 0.91,

  "techniques": [
    {
      "id": "T1059.001",
      "name": "PowerShell",
      "confidence": 0.95
    }
  ],

  "evidence": [
    "Encoded PowerShell command",
    "External network connection",
    "Rare behavior for this user",
    "Destination IP has suspicious reputation"
  ],

  "recommended_actions": [
    "Isolate endpoint",
    "Investigate PowerShell process tree",
    "Review authentication events",
    "Search for lateral movement"
  ],

  "human_review_required": true
}

27. AI Detection Tuning

La IA también puede ayudarnos a mejorar las detecciones existentes.

Podemos proporcionar:

Detection:
PowerShell execution

Alerts:
12,432

Confirmed incidents:
14

False positives:
12,418

El modelo puede analizar patrones de los falsos positivos y proponer hipótesis de reducción de ruido.

28. Detections adaptativas

Una detección tradicional puede utilizar thresholds estáticos.

failed_logins > 10

Pero una organización puede tener usuarios con comportamientos muy diferentes.

Podemos evolucionar hacia:

baseline(user)
       +
historical_behavior
       +
peer_group
       +
current_event
       =
adaptive_detection

Esto nos acerca a UEBA y detección basada en comportamiento.

29. Threat Hunting

Detection Engineering y Threat Hunting están estrechamente relacionados.

El Threat Hunter puede formular:

"¿Tenemos evidencias de PowerShell
ejecutándose de forma anómala
durante los últimos 30 días?"

La IA puede convertir esa pregunta en múltiples consultas para diferentes fuentes de datos.

30. Arquitectura completa de Detection + AI

31. Feedback Loop

El verdadero salto de calidad aparece cuando el sistema aprende de las investigaciones.

Detection
    ↓
Alert
    ↓
Analyst
    ↓
True Positive / False Positive
    ↓
Feedback
    ↓
Detection Tuning
    ↓
Improved Detection

Esto permite construir un sistema operativo de seguridad progresivamente más eficiente.

32. Métricas avanzadas

33. Preguntas de comprensión

34. Ejercicio de arquitectura

35. Proyecto de la Week 08

36. Entregable

El alumno deberá entregar:

37. Errores que debemos evitar

38. Recursos recomendados

39. La arquitectura que estamos construyendo

Después de ocho semanas, nuestro proyecto empieza a tomar una forma mucho más clara.

40. Cierre de la Week 08

Durante esta semana hemos convertido nuestro concepto de AI SOC Analyst en algo mucho más potente: un sistema capaz de participar también en la creación, validación, análisis y evolución de las propias detecciones.

El siguiente gran paso será utilizar estas capacidades para construir un verdadero sistema de Threat Hunting aumentado por IA, capaz de partir de una hipótesis, consultar automáticamente múltiples fuentes, encontrar patrones desconocidos y generar nuevas hipótesis de investigación.