CYBER 02 · ADVANCED

Security Telemetry & Detection Engineering

En esta semana vamos a transformar la infraestructura de red en una fuente de inteligencia de seguridad. Partimos de un alumno que ya domina redes y sistemas. Por tanto, no vamos a explicar qué es TCP, DNS, HTTP, routing o un firewall. Vamos a estudiar cómo capturar, normalizar, enriquecer, correlacionar y analizar esos datos para construir detecciones capaces de alimentar nuestro futuro AI Security Command Center.

Advanced 14–18 horas PCAP Zeek Suricata DNS Analytics Python ML Features Detection Engineering

Cómo trabajarás esta semana

No se trata de leer teoría y responder un test. Cada concepto seguirá una progresión que permita al alumno resolver los problemas incluso cuando no tenga la respuesta inmediatamente disponible.

📖
Aprende

🧪
Practica

💡
Pista

✅
Resuelve

🚀
Profundiza

Regla de la semana: Antes de abrir una solución debes intentar resolver el problema. Las pistas no están pensadas para darte la respuesta, sino para ayudarte a desarrollar el razonamiento que utilizaría un Detection Engineer.

La misión de CYBER 02

Una organización puede generar millones de eventos de red cada día. El problema de seguridad moderno no es únicamente obtener esos eventos. Es convertirlos en señales accionables.

Network
Traffic

→

Zeek

→

Suricata

→

Normalize

→

Enrich

→

Features

→

Detection

→

Risk

EVOLUCIÓN DEL DATO

Packet
   ↓
Flow
   ↓
Event
   ↓
Feature
   ↓
Detection
   ↓
Finding
   ↓
Risk
   ↓
Investigation

Objetivos técnicos

01 · Security Telemetry

Diseñar una arquitectura capaz de capturar las señales necesarias para investigar incidentes.

02 · Network Analytics

Extraer comportamiento útil de PCAP, flows, DNS, HTTP y TLS.

03 · Detection Engineering

Construir detecciones reproducibles y medibles.

04 · Feature Engineering

Convertir telemetría en variables utilizables por algoritmos estadísticos y ML.

05 · Behavioral Analytics

Construir baselines y detectar desviaciones.

06 · AI Security

Preparar la información para que posteriormente pueda ser analizada por modelos de IA.

01 · Security Telemetry Architecture

La primera pregunta no debe ser "¿qué modelo de IA utilizo?". Debe ser: ¿qué necesito observar?

APRENDE

Las cuatro capas de telemetría

Packet telemetry

Representa la observación más granular. Puede incluir:

IP addresses
ports
protocols
TCP flags
packet size
timestamps
payload metadata

Flow telemetry

Agrega paquetes en conversaciones. Esto reduce volumen y proporciona una visión mucho más adecuada para analytics.

Application telemetry

Permite entender protocolos como: DNS, HTTP, TLS, SMTP, SSH, DHCP, etc.

Security telemetry

Incluye eventos generados por: IDS, IPS, firewalls, proxies, VPN, EDR, authentication systems y otros controles.

EJEMPLO DE ARQUITECTURA

                    INTERNET
                        │
                        ▼
                 ┌────────────┐
                 │   TAP/SPAN │
                 └─────┬──────┘
                       │
              ┌────────┴────────┐
              │                 │
            Zeek             Suricata
              │                 │
              └────────┬────────┘
                       │
                       ▼
                Event Pipeline
                       │
                       ▼
                 Data Lake/SIEM
                       │
                       ▼
                 Detection Layer

🧠 Ejercicio guiado

Una organización quiere detectar:

DNS tunneling
port scanning
beaconing
lateral movement
data exfiltration

¿Qué fuentes de telemetría utilizarías?

💡 Pista: No pienses todavía en herramientas. Piensa en qué evidencia necesitarías para demostrar cada comportamiento.

✅ Ver solución razonada

Para DNS tunneling necesitaremos DNS query metadata. Para scanning necesitaremos observar: origen → múltiples destinos/puertos → ventana temporal. Para beaconing necesitamos timestamps, destinos y periodicidad. Para lateral movement necesitamos especialmente telemetría East-West. Para exfiltration necesitaremos volumen, dirección, destino, contexto del activo y, si es posible, información de aplicación.

Una arquitectura razonable sería combinar: Zeek + Suricata + firewall + DNS + identity + endpoint telemetry.

02 · PCAP → Security Evidence

Un PCAP no es una alerta. Es materia prima. Nuestro trabajo consiste en convertir esa materia prima en evidencias que puedan ser analizadas.

APRENDE

Del paquete al comportamiento

Un pipeline de análisis puede seguir este proceso:

PCAP

→

Packets

→

Flows

→

Protocols

→

Events

→

Features

La clave es que cada transformación debe responder a una pregunta de seguridad.

EJEMPLO

Host: 10.10.20.44

Connections:
10.10.20.1:53
10.10.20.5:445
10.10.20.6:445
10.10.20.7:445
10.10.20.8:445
10.10.20.9:445
10.10.20.10:445

Possible behavior:

Multiple internal SMB destinations
within a short time window.

Potential signal:
Lateral movement / discovery.

🧪 Practica

A partir de un PCAP de laboratorio autorizado, extrae:

Hosts únicos
Puertos únicos
Protocolos
Destinos principales
Volumen por host
Conexiones fallidas
Conexiones periódicas

💡 Pista: No empieces buscando malware. Primero construye un inventario del comportamiento.

🛠️ Herramientas recomendadas

Puedes utilizar:

Wireshark
tshark
tcpdump
Zeek
Python + pandas

La idea es comprobar que diferentes herramientas pueden producir diferentes representaciones del mismo tráfico.

03 · Zeek como Security Sensor

APRENDE

Por qué Zeek es importante

Zeek convierte tráfico de red en logs estructurados que pueden ser procesados posteriormente. Entre otros, podemos trabajar con:

conn.log
dns.log
http.log
ssl.log
ssh.log
files.log

Esto es extremadamente interesante para IA porque los datos ya están mucho más cerca de una representación estructurada del comportamiento.

CONNECTION RECORD

ts
uid
id.orig_h
id.orig_p
id.resp_h
id.resp_p
proto
service
duration
orig_bytes
resp_bytes
conn_state

🧠 Ejercicio

Tenemos:

orig_h = 10.0.0.15
resp_h = 10.0.0.25
resp_p = 445
duration = 0.12
orig_bytes = 84
resp_bytes = 0
conn_state = S0

¿Qué hipótesis investigarías?

💡 Pista: No interpretes un registro aislado como ataque. Pregunta qué significa una colección de registros con el mismo patrón.

✅ Respuesta razonada

El registro muestra un intento de conexión que no parece haber completado una sesión. Si encontramos muchos registros similares:

mismo origen
muchos destinos
mismo puerto
intervalo temporal corto
muchas conexiones sin completar

podríamos tener una señal compatible con scanning. Pero debemos distinguirlo de:

vulnerability scanners
monitorización
errores de configuración
servicios legítimos

Por eso la detección debe producir una señal, no un veredicto automático.

04 · Suricata y Rule-Based Detection

APRENDE

Deterministic Detection

Suricata permite incorporar detecciones basadas en reglas y generar eventos estructurados. La gran ventaja es la determinación:

Traffic
   │
   ▼
Rule matching
   │
   ├── match → alert
   │
   └── no match → continue

Pero esta aproximación tiene una limitación: solo puede detectar aquello que hemos sabido definir.

Concepto clave: Las reglas y la IA no son sustitutos. Una arquitectura madura utiliza reglas para comportamientos conocidos y ML/estadística para encontrar desviaciones y patrones más complejos.

🧪 Ejercicio

Diseña conceptualmente una detección para: "Un endpoint intenta conectarse a muchos puertos de múltiples servidores internos durante 30 segundos."

💡 Pista: Necesitas al menos: source + destination + port + timestamp. Pero piensa qué agregaciones necesitarías.

✅ Solución

Podríamos calcular:

unique_dst_ips
unique_dst_ports
connection_attempts
failed_connections
time_window
connection_rate

Y producir una detección:

IF
unique_dst_ips > threshold
AND
unique_dst_ports > threshold
AND
time_window < threshold

THEN

generate discovery/scanning signal

Después deberíamos añadir contexto: asset_role, scanner_authorization, historical_behavior, user, criticality.

05 · DNS Analytics

DNS es uno de los mejores ejemplos para aprender Detection Engineering porque podemos combinar señales estadísticas, temporales y contextuales.

Query length

Longitudes anormalmente elevadas pueden ser una señal.

Entropy

Una elevada aleatoriedad puede resultar interesante en determinados patrones.

NXDOMAIN

Un incremento puede indicar comportamientos anómalos dependiendo del contexto.

Subdomain diversity

Miles de subdominios únicos pueden requerir investigación.

FEATURE SET

dns_query_length
dns_entropy
dns_queries_per_minute
nxdomain_ratio
unique_subdomains
domain_frequency
domain_age
first_seen
last_seen

🧪 Caso práctico

Host: WS-1042

queries/min:       437
avg_length:        81
entropy:           4.93
NXDOMAIN ratio:    0.41
unique_subdomains: 1821
known_domain:      NO

¿Generarías una alerta?

💡 Pista 1: No preguntes "¿es malware?". Pregunta "¿qué evidencia tengo?".

💡 Pista 2: Busca la combinación de señales.

💡 Pista 3: Compara contra el comportamiento histórico del endpoint.

✅ Respuesta razonada

Existe suficiente evidencia para elevar la prioridad de investigación. La combinación:

alto volumen
queries largas
entropy elevada
alto NXDOMAIN ratio
gran cantidad de subdominios
dominio desconocido

es compatible con comportamientos que merecen investigación. Pero todavía no podemos afirmar DNS tunneling. La siguiente fase debería correlacionar:

proceso responsable
usuario
destino
reputación
historial
otras conexiones del endpoint

🚀 Reto avanzado

Construye un score entre 0 y 1. Por ejemplo:

score =

0.20 * entropy_score
+
0.20 * length_score
+
0.20 * frequency_score
+
0.15 * nxdomain_score
+
0.15 * rarity_score
+
0.10 * baseline_deviation

Después analiza cómo cambia el resultado si eliminamos cada feature. Objetivo: determinar qué señales realmente aportan capacidad de detección.

06 · Beaconing Detection

APRENDE

Detectar periodicidad

Supongamos que un endpoint genera:

10:00:01
10:05:02
10:10:01
10:15:03
10:20:02
10:25:01

Los intervalos son aproximadamente:

La baja variabilidad es una señal interesante. Pero nuevamente: señal ≠ veredicto.

🧠 Ejercicio

Calcula conceptualmente:

media
mediana
desviación estándar
jitter
coefficient of variation

💡 Pista: Un beacon puede tener una periodicidad casi perfecta o utilizar jitter para dificultar la detección. Por tanto, no busques solamente intervalos idénticos.

✅ Solución conceptual

El objetivo es representar la regularidad. Una posible feature sería:

coefficient_of_variation =
standard_deviation / mean

Cuanto menor sea el valor, mayor regularidad existe. Pero el sistema debe combinarlo con:

destino
reputación
proceso
usuario
volumen
baseline

07 · Network Scanning Detection

Un scanner legítimo y un atacante pueden producir patrones similares. Por eso este módulo es especialmente importante.

DETECCIÓN DEMASIADO SIMPLE

IF
connections > 100

THEN
ALERT

DETECCIÓN MEJORADA

features:

unique_dst_ips
unique_dst_ports
failed_connections
connection_rate
time_window
protocol_distribution
historical_frequency
asset_role
scanner_authorized

🧠 Pregunta

Un servidor de seguridad autorizado realiza 500 conexiones a diferentes puertos cada noche. Nuestro modelo genera una alerta HIGH. ¿Qué está fallando?

💡 Pista: La pregunta no es si la detección ha encontrado una anomalía. La pregunta es si esa anomalía debería generar una alerta de alta prioridad.

✅ Respuesta

Probablemente el detector está funcionando, pero el sistema de contextualización es insuficiente. Debemos diferenciar: Detection Score de Risk Score . El comportamiento puede ser altamente anómalo pero perfectamente legítimo.

08 · Behavioral Baselines

Para detectar anomalías debemos tener una representación del comportamiento esperado.

HOST BASELINE

HOST: WS-1042

Typical hours:
08:00 - 19:00

Typical DNS:
300 queries/hour

Typical external destinations:
Microsoft
Google
GitHub

Typical protocols:
HTTPS
DNS

Typical upload:
50-400 MB/day

Typical countries:
ES
DE
NL

NUEVO COMPORTAMIENTO

03:17

SSH connection
to unknown external IP

2.4 GB upload

Country:
UNKNOWN

Destination:
never seen before

Baseline deviation:
HIGH

🧪 Ejercicio

¿Es necesariamente un ataque?

💡 Pista: Piensa en un administrador trabajando fuera de horario. Ahora piensa en un endpoint de usuario. ¿Cambiaría tu decisión?

✅ Solución

Sí. El contexto del activo modifica radicalmente el significado de la anomalía. El mismo evento puede ser:

normal para un bastion host
anómalo para un workstation
esperado para un backup server
crítico para un servidor sensible

Por eso necesitamos incorporar asset context.

09 · Feature Engineering

APRENDE

Convertir eventos en variables

Los modelos de ML no reciben directamente "un ataque". Reciben representaciones numéricas o categóricas del comportamiento.

Categoría	Features	Uso
Temporal	hour, interval, frequency	Beaconing
Network	bytes, packets, ports	Volume / scanning
Behavior	first_seen, rarity	Anomaly
DNS	entropy, length, NXDOMAIN	Tunneling
Context	criticality, role	Risk
Threat Intel	reputation, IOC match	Enrichment

🚀 Reto avanzado

Construye un feature vector para evaluar un endpoint.

{
  "connection_rate": 142,
  "unique_destinations": 38,
  "unique_ports": 19,
  "dns_entropy": 4.91,
  "nxdomain_ratio": 0.34,
  "beacon_periodicity": 0.91,
  "rare_destination": 1,
  "baseline_deviation": 0.84,
  "asset_criticality": 0.80
}

Después define qué features deberían entrar en:

Detection Score
Risk Score
LLM Investigation Context

10 · Detection ≠ Risk ≠ Verdict

Este concepto será fundamental durante todo el curso.

Raw Event

→

Detection

→

Context

→

Risk

→

Investigation

Detection Score

¿Qué grado de evidencia existe de que el comportamiento es anómalo o coincide con una técnica?

Risk Score

¿Qué impacto tendría si el comportamiento fuese malicioso?

Verdict

¿Tenemos suficiente evidencia para clasificar el incidente?

LLM Analysis

¿Cómo podemos ayudar al analista a investigar y explicar las evidencias?

Arquitectura clave: Un evento puede tener:

Detection = 0.92
Risk = 0.35
porque el comportamiento es muy anómalo, pero pertenece a un scanner autorizado.

LAB 01 · Monta el laboratorio

HANDS-ON

Docker + Network Sensors

Construiremos un entorno controlado.

Instala Docker.
Crea una red aislada.
Levanta un servidor web.
Levanta un cliente.
Genera tráfico HTTP.
Genera consultas DNS.
Genera conexiones repetitivas.
Captura el tráfico.
Procesa el tráfico con Zeek.
Analiza los resultados.

docker network create cyberlab

docker run -d \
  --name web \
  --network cyberlab \
  nginx

docker run -it \
  --name client \
  --network cyberlab \
  ubuntu

💡 Pista: No intentes construir todavía un SOC completo. El objetivo de este laboratorio es comprender el ciclo: traffic → telemetry → event

✅ Resultado esperado

Al terminar deberías poder explicar: 1. dónde se genera el tráfico; 2. dónde se captura; 3. cómo se transforma; 4. qué logs produce el sensor; 5. qué información puedes convertir en features.

LAB 02 · DNS Anomaly Detector

PYTHON

Construye un detector estadístico

Crea un programa que reciba registros DNS y calcule las principales features.

import pandas as pd

df = pd.read_csv("dns.csv")

df["query_length"] = (
    df["query"]
    .str.len()
)

print(
    df[
        [
            "query",
            "query_length"
        ]
    ]
)

🧪 Primera iteración

Añade:

query length
queries per minute
NXDOMAIN ratio
unique subdomains

💡 Pista: Agrupa por host y ventana temporal. No calcules solamente estadísticas globales.

🚀 Reto avanzado

Añade entropy. Conceptualmente:

from collections import Counter
from math import log2

def entropy(value):

    counts = Counter(value)

    total = len(value)

    return -sum(
        (count/total) *
        log2(count/total)
        for count in counts.values()
    )

Después compara la distribución de entropy entre dominios normales y dominios anómalos.

LAB 03 · Beaconing Detector

BEHAVIORAL ANALYTICS

Detecta conexiones periódicas

Construye una función que reciba timestamps y devuelva:

mean interval
standard deviation
jitter
coefficient of variation
periodicity score

timestamps:

00:00
00:05
00:10
00:15
00:20
00:25

💡 Pista: Convierte primero timestamps a segundos. Después calcula diferencias consecutivas.

✅ Solución conceptual

La transformación es:

timestamps
    ↓
seconds
    ↓
diff()
    ↓
intervals
    ↓
statistics
    ↓
periodicity score

Una periodicidad elevada puede ser una señal de beaconing, pero no constituye por sí misma un veredicto.

LAB 04 · Detection Fusion

ADVANCED

Combina múltiples detecciones

Tenemos:

DNS anomaly        0.72
Beaconing          0.81
Rare destination   0.92
Threat Intel       1.00
Asset criticality  0.80
User anomaly       0.30

Construye un Risk Engine.

💡 Pista: No todas las señales deberían tener el mismo peso. Además, algunas pueden estar correlacionadas.

✅ Solución de referencia

Una primera versión podría utilizar pesos:

risk =

0.20 * dns_anomaly
+
0.20 * beaconing
+
0.20 * rare_destination
+
0.20 * threat_intel
+
0.20 * asset_criticality

Pero esta es solo una primera aproximación. Una arquitectura real debería estudiar:

correlación entre features
calibración
historical outcomes
false positives
analyst feedback

11 · Mapping a MITRE ATT&CK

Las detecciones deben poder relacionarse con comportamientos y técnicas conocidas.

Comportamiento	Posible técnica	Telemetría
Port scanning	Network Service Scanning	Flow / firewall / Zeek
Internal discovery	Remote System Discovery	East-West traffic
Service discovery	Network Service Discovery	Network telemetry

🧠 Ejercicio

Para cada detección que hayas construido, documenta:

Qué comportamiento detecta.
Qué evidencia necesita.
Qué features utiliza.
Qué técnica ATT&CK puede relacionarse.
Qué falsos positivos esperas.
Qué contexto reduce el riesgo.

💡 Pista: Una detección profesional no debería documentar solamente "qué alerta genera". Debe explicar por qué existe y cómo debe investigarse.

12 · Troubleshooting de Detection Engineering

Problema 01 · Demasiadas alertas

Tu detector genera: 85.000 alertas/día. El SOC no puede investigarlas. ¿Qué haces?

💡 Pista: No empieces cambiando arbitrariamente el threshold. Primero determina qué población está generando las alertas.

✅ Respuesta razonada

Debemos estudiar:

distribution of scores
false positive rate
asset types
authorized scanners
scheduled jobs
repeated alerts
duplicate events

Después podemos:

agrupar eventos
suprimir duplicados
añadir contexto
calibrar thresholds
priorizar por risk

La solución no es simplemente "subir el threshold".

Problema 02 · El modelo deja de detectar

Hace tres meses el detector funcionaba muy bien. Ahora su rendimiento ha disminuido. ¿Qué investigarías?

💡 Pista: Piensa en cómo cambia el comportamiento de una organización.

✅ Respuesta

Investigaríamos:

concept drift
data drift
cambios de infraestructura
nuevas aplicaciones
nuevos patrones de usuarios
cambios en DNS
cambios en cloud
cambios en políticas

Un modelo de seguridad no puede considerarse "terminado" después del entrenamiento.

13 · Knowledge Test

Intenta responder antes de abrir cada solución.

¿Por qué es importante normalizar la telemetría?

A) Para eliminar todos los logs
B) Para facilitar correlación y análisis
C) Para aumentar el tráfico
D) Para sustituir el firewall

💡 Pista

Piensa en qué ocurre cuando diferentes sistemas utilizan nombres y formatos distintos para representar el mismo evento.

✅ Respuesta

B. La normalización permite que diferentes fuentes puedan ser correlacionadas de manera consistente.

¿Es beaconing suficiente para afirmar C2?

A) Sí
B) No

💡 Pista

Busca la diferencia entre una señal y un veredicto.

✅ Respuesta

B. La periodicidad es una señal. Necesitamos contexto adicional.

¿Qué representa un baseline?

A) Un malware
B) Comportamiento esperado
C) Una regla de firewall
D) Un protocolo

💡 Pista

Sirve como referencia para detectar desviaciones.

✅ Respuesta

¿Qué diferencia Detection Score y Risk Score?

A) Ninguna
B) Detection mide evidencia/anomalía; Risk incorpora impacto y contexto
C) Risk solo depende de IP
D) Detection siempre implica ataque

💡 Pista

Piensa en el scanner autorizado.

✅ Respuesta

B. Un comportamiento puede ser muy anómalo pero tener bajo riesgo si es esperado y autorizado.

¿Qué es feature engineering?

A) Diseñar una interfaz
B) Transformar datos en variables útiles para análisis/ML
C) Configurar DNS
D) Crear usuarios

💡 Pista

Piensa en cómo convertirías "muchas conexiones" en una variable.

✅ Respuesta

B. Por ejemplo: unique_destinations, connection_rate, dns_entropy, baseline_deviation.

¿Qué problema tiene un threshold fijo?

A) Ninguno
B) Ignora contexto y cambios de comportamiento
C) Es imposible implementarlo
D) Solo funciona con DNS

💡 Pista

¿Generan el mismo tráfico un workstation, un scanner y un backup server?

✅ Respuesta

¿Por qué combinar reglas y ML?

A) Porque cubren diferentes tipos de detección
B) Porque ML no funciona
C) Porque las reglas son inútiles
D) Para eliminar los logs

💡 Pista

Known patterns y unknown deviations no son exactamente el mismo problema.

✅ Respuesta

¿Qué problema puede aparecer si el comportamiento normal cambia?

A) Concept drift
B) NAT
C) TCP reset
D) DNS poisoning automáticamente

💡 Pista

El modelo aprendió una distribución histórica.

✅ Respuesta

14 · Expert Assessment

Caso 01 · 10.000 alertas de scanning

Tienes una red corporativa. Un detector genera:

10.000 alerts/day

False positives:
~82%

Top source:
Vulnerability Scanner

Top destination:
Internal servers

Diseña una estrategia para reducir el ruido sin perder cobertura.

💡 Pista

No empieces eliminando el detector. Empieza clasificando el tráfico legítimo.

✅ Solución de referencia

Una estrategia razonable:

Identificar scanners autorizados.
Crear asset identity.
Añadir scanner_authorized como contexto.
Mantener la detección.
Reducir risk score cuando el origen está autorizado.
Mantener detección alta si aparecen otros indicadores.

Esto mantiene visibilidad sin generar 10.000 incidentes innecesarios.

Caso 02 · ¿Regla, ML o LLM?

Asigna cada problema a la tecnología más adecuada:

Problema	Solución
IOC conocido	?
Periodicidad anómala	?
Correlación de 15 eventos	?
Explicar un incidente al analista	?

💡 Pista

Piensa: deterministic → statistical/ML → correlation → reasoning.

✅ Solución

IOC conocido: rule / threat intelligence
Periodicidad: statistical / ML
Correlación: detection/risk engine
Explicación: LLM

15 · Preparando la IA

Ahora que tenemos detecciones estructuradas, podemos empezar a pensar en IA. La IA no debería recibir millones de eventos sin procesar. Debe recibir contexto.

Raw Logs

→

Detection

→

Correlation

→

Risk

→

LLM Analyst

CONTEXTO QUE RECIBIRÍA LA IA

Asset:
WS-1042

User:
employee-42

Asset criticality:
HIGH

Detection:
DNS anomaly

Detection score:
0.91

Signals:
- high entropy
- high query volume
- rare domain
- periodic behavior

Threat intelligence:
unknown

Historical baseline:
strong deviation

Related network events:
3

Related endpoint events:
2

Esto cambia completamente el problema. El LLM ya no necesita "buscar un ataque" en millones de paquetes. Recibe una investigación preprocesada y puede ayudar a:

resumir evidencias
correlacionar señales
generar hipótesis
proponer preguntas de investigación
explicar por qué una alerta es relevante

WEEK 02 DELIVERABLE

Tu primer Detection Pipeline

Al finalizar CYBER 02 debes tener una primera versión funcional del pipeline que posteriormente se integrará en el AI Security Command Center.

TARGET ARCHITECTURE

                 NETWORK
                    │
          ┌─────────┴─────────┐
          │                   │
        ZEEK              SURICATA
          │                   │
          └─────────┬─────────┘
                    │
              NORMALIZATION
                    │
               ENRICHMENT
                    │
             FEATURE ENGINE
                    │
        ┌───────────┴───────────┐
        │                       │
   RULE DETECTION          ANOMALY MODEL
        │                       │
        └───────────┬───────────┘
                    │
              CORRELATION
                    │
                RISK ENGINE
                    │
              SECURITY EVENT
                    │
              AI COMMAND
                 CENTER

Entregables

✓ PCAP analizado

✓ Zeek funcionando

✓ Suricata funcionando

✓ Dataset normalizado

✓ DNS detector

✓ Beaconing detector

✓ Scanning detector

✓ Feature engineering

✓ Baseline

✓ Detection score

✓ Risk score

✓ MITRE mapping

✓ Investigation context

✓ JSON final

FORMATO FINAL

{
  "asset": "WS-1042",

  "detection": {
    "type": "dns_anomaly",
    "score": 0.91
  },

  "signals": [
    "high_entropy",
    "rare_domain",
    "high_query_rate",
    "periodic_behavior"
  ],

  "context": {
    "asset_criticality": 0.80,
    "baseline_deviation": 0.87
  },

  "risk_score": 0.89,

  "priority": "HIGH",

  "mitre": [
    "Command and Control"
  ],

  "recommended_investigation": [
    "identify originating process",
    "check endpoint telemetry",
    "investigate destination",
    "review historical DNS activity"
  ]
}

Este objeto JSON es el puente hacia CYBER 03. En los siguientes módulos iremos añadiendo más fuentes de evidencia hasta construir un sistema capaz de correlacionar:

Network + Endpoint + Identity + Cloud + Threat Intelligence + AI

Referencias y documentación

Zeek Network Security Monitor.

https://zeek.org/

Zeek Documentation Documentación oficial y referencia de logs.

https://docs.zeek.org/

Suricata IDS/IPS y Network Security Monitoring.

https://suricata.io/

Suricata Documentation Documentación técnica oficial.

https://docs.suricata.io/

Wireshark Network protocol analyzer.

https://www.wireshark.org/

MITRE ATT&CK Framework para tácticas y técnicas de adversarios.

https://attack.mitre.org/

NIST Cybersecurity Framework Framework para gestionar riesgo de ciberseguridad.

NIST CSF

NIST AI Risk Management Framework Framework para gestión del riesgo asociado a IA.

NIST AI RMF

CYBER 02 · Mastery Checklist

✓ Sé diseñar una arquitectura de Security Telemetry.

✓ Sé analizar PCAP.

✓ Sé utilizar Zeek.

✓ Comprendo Suricata y las reglas IDS.

✓ Sé analizar DNS.

✓ Sé construir features.

✓ Sé detectar patrones de beaconing.

✓ Sé detectar scanning.

✓ Comprendo lateral movement.

✓ Sé construir un baseline.

✓ Sé diferenciar anomaly de attack.

✓ Sé diferenciar detection de risk.

✓ Sé construir un risk score.

✓ Sé reducir falsos positivos mediante contexto.

✓ Sé relacionar detecciones con MITRE ATT&CK.

✓ Sé preparar contexto para un LLM.

✓ He construido un detection pipeline.

✓ Tengo el primer componente del AI Security Command Center.