Monitoreo de amenazas y alertas SOC

Resumen breve

El eficiente SOC se construye sobre tres ballenas: la plenitud de la telemetría, las detecciones de calidad y la disciplina operativa (priorización, escaladas, post-incidente y mejoras). Objetivo: identificar rápidamente a los atacantes a través de indicadores de comportamiento y firma, reaccionar dentro de SLO y minimizar los falsos positivos sin perder cobertura.

Arquitectura de monitoreo SOC

SIEM - Recepción, normalización y correlación de eventos; dashboards, búsqueda, alerta.
UEBA es una analítica conductual de usuarios/hosts, perfiles básicos y anomalías.
SOAR - automatización de la respuesta: enriquecimiento de alertas (TI, CMDB), orquestación de acciones de contenido.
TI (Threat Intelligence): fides IOC/TTP/vulnerabilidades críticas; contexto para las reglas y el enriquecimiento.
Almacenamiento - «caliente» 7-30 días para investigaciones, «frío» 90-365 + para cumplimiento/retrospectiva.

Fuentes de registro (mínimamente suficientes)

• IdP/SSO (OIDC/SAML), MFA, PAM, VPN/ZTNA, directorios (AD/AAD).

• EDR/AV, Sysmon/ETW (Windows), auditd/eBPF (Linux), MDM (móviles).

• Firewall (L3/L7), WAF/WAAP, balanceadores (NGINX/Envoy), DNS, proxy, NetFlow/sFlow/Zeek.

• CloudTrail/Activity Logs, KMS/Key Vault, eventos IAM, Kubernetes (audit, API server), seguridad de contenedores.

• Auditoría de Almirantes, acceso a PII/pagos, DDL/derechos, eventos empresariales críticos (withdraw, bonus, payout).

• Phishing/spam Detect, DLP, clics de URL, archivos adjuntos.

Normalización: formato único (por ejemplo, ECS/CEF), campos obligatorios: 'timestamp', 'src/dst ip', 'user', 'action', 'resource', 'resultado', 'request _ id/trace _ id'.

Taxonomía de amenazas y mapeo ATT&CK

Construya reglas y tablas en MITRE ATT&CK: Acceso Inicial, Ejecución, Persistencia, Escalamiento Privilegial, Evolución de Defensa, Acceso Credencial, Descubrimiento, Movimiento Lateral, C2, Colección/Ejecución/Impacto.
Para cada táctica, las detecciones mínimas y los paneles de control son «coverage vs. fidelity».

Política de alerta y priorización

• P1 (Crítico): C2 activo, éxito ATO/robo de tokens, cifrado, exfiltración de pago/PII.
• P2 (High): implementación en infraestructura/nube, escaladas de privilegios, elusión de MFA.
• P3 (Medium): anomalía sospechosa, repetidos intentos fallidos, comportamiento raro.
• P4 (Bajo): ruido, hipótesis, coincidencias TI sin confirmación.
• Escaladas: P1 - inmediatamente en llamada (24 × 7), P2 - en horario de oficina ≤ 1 h, el resto a través de colas.
• Duplicación: agregue alertas por objeto/sesión para evitar una «tormenta».

SLI/SLO/SLA SOC

SLI: tiempo de detección (MTTD), tiempo de confirmación (MTTA), tiempo hasta contenido (MTTC), porcentaje de falsos positivos (FP) y omitidos (FN) en clústeres de scripts.

• MTTD P1 ≤ 5 minutos; MTTC P1 ≤ 30 minutos.
• FP-rate según las reglas de alta severidad ≤ 2 %/día.
• La cobertura de las técnicas clave ATT&CK ≥ del 90% (presencia de al menos una detección).
• SLA (externo): acuerde con el negocio (p. ej., notificación P1 a los propietarios ≤ 15 min).

Reglas de detección: firmas, heurística, comportamiento

Sigma (ejemplo: acceso sospechoso a la administración fuera del país)

yaml title: Admin Panel Access Outside Allowed Country id: 5c6c9c1d-8f85-4a0e-8c3a-1b7cabc0b001 status: stable logsource:
product: webserver detection:
selection:
http. request. uri: /admin http. response. status: 200 filter_country:
geoip. country: /^(?!UA    PL    GE)$/
condition: selection and filter_country level: high fields: [user, ip, geoip. country, user_agent, trace_id]
falsepositives:
- Service connections from SOC/VPN (add allow-list)

KQL (ejemplo: inicio de sesión fallido + cuentas diferentes de la misma IP)

kusto
SigninLogs where ResultType!= 0 summarize fails=count(), users=dcount(UserPrincipalName) by bin(TimeGenerated, 10m), IPAddress where fails > 50 and users > 5

Aplicación (SQL, acceso a PII fuera de horario)

sql
SELECT user_id, count() AS reads
FROM audit_pii
WHERE ts > now() - interval '1 hour'
AND user_id NOT IN (SELECT user_id FROM roster WHERE role IN ('DPO','Support'))
AND extract(hour from ts) NOT BETWEEN 8 AND 21
GROUP BY 1 HAVING count() > 5;

UEBA y contexto

Perfiles de actividad básica por usuario/roles/servicios (relojes, ASN, dispositivos).
Anomalías: IP/ASN raras, nuevo dispositivo, secuencias de API inusuales, cambio brusco en el tiempo de actividad.
Risk score eventos = señales (TI, anomalía, sensibilidad del recurso) × peso.

SOAR y automatización de respuestas

Enriquecimiento: Reputación TI IP/dominio/hash, CMDB (quién es el propietario del host/servicio), HR (estado del empleado), rol IAM.
Acciones: aislamiento de host (EDR), bloqueo de IP/ASN/JA3, revocación temporal de tokens/sesiones, rotación forzada de secretos, prohibición de retiros/congelación de bonos.
Reiles de guardia: para acciones críticas - appruvio de dos factores; TTL en los bloqueos.

Procesos SOC

1. Triage: verificación de contexto, deduplicación, conciliación con TI, clasificación primaria por ATT&CK.
2. Investigación: recolección de artefactos (PCAP/EDR/logs), hipótesis, línea de tiempo, evaluación de daños.
3. Containment/Eradication: aislamiento, revocación de claves/tokens, parcheo, bloqueo.
4. Recuperación: control de limpieza, rotación, monitoreo de repetición.
5. RCA/Lecciones: post-incidente, actualización de reglas/dashboards, adición de casos de prueba.

Afinación y calidad de detección

Modo shadow para nuevas reglas: contar, pero no bloquear.
Paquete de regresión: biblioteca de eventos «buenos/malos» para pruebas de reglas CI.
FP-remediación: excepciones por vías/roles/ASN; la regla de «mal por defecto» es sólo después de los canarios.
Drift-monitoring: cambio de actividad subyacente → adaptación de umbrales/modelos.

Operativo: alertas activas, P1/P2, mapa de ataque (geo/ASN), «talkers top», cinta de coincidencias TI.
Tácticas: cobertura ATT y CK, tendencias FP/FN, MTTD/MTTC, fuentes «ruidosas».
Negocios: incidentes por producto/región, impacto en KPI (conversión, Time-to-Wallet, fallos de pago).

Almacenamiento, privacidad y cumplimiento

Retiro: mínimo 90 días de registros «cálidos», ≥ 1 año de archivo donde se requiere (fintech/reguladores).
PII/secretos: tokenización/enmascaramiento, acceso por roles, cifrado.
Requisitos legales: informes de incidentes, almacenamiento de cadenas de decisión, consistencia de relojes (NTP).

Purple Team y verificación de cobertura

Threat hunting: hipótesis sobre TTP (por ejemplo, T1059 PowerShell), solicitudes ad-hoc en SIEM.
Purple Team: sprints colaborativos de Red + Blue: inicie TTP, compruebe los desencadenantes y perfeccione las reglas.
Autotestas de los niños: re-play periódico de eventos de referencia (pruebas atómicas) en prod no-prod y prod «sombreado».

Características específicas de iGaming/fintech

Dominios críticos: inicio de sesión/registro, depósitos/retiros, promociones, acceso a PII/fin. informes.
Escenarios: ATO/credential stuffing, prueba de tarjetas, bonificación abusiva, acceso a pagos con información privilegiada.
Reglas: velocity on '/login ', '/withdraw', idempotencia y HMAC webhooks, mTLS a PSP, detección para acceder a tablas con PAN/PII.
Los desencadenantes del negocio: un fuerte aumento de los fallos de pago/chargeback, anomalías en las conversiones, picos de depósitos «cero».

Ejemplos de runbook (abreviado)

P1: ATO confirmada y retirada de fondos

1. SOAR bloquea la sesión, retira los tokens refresh, congela las conclusiones (TTL 24 h).
2. Notificar al propietario del producto/finanzas; ejecutar password reset/2FA-rebind.
3. Compruebe las cuentas adyacentes mediante el gráfico device/IP/ASN; ampliar la unidad por clústeres.
4. RCA: agregue la detección de repeticiones, amplifique la velocidad-umbral en '/withdraw '.

P2: Exequia en el servidor (T1059)

1. Aislamiento EDR, eliminación de memoria/artefactos.
2. Inventario de los últimos deployes/secretos; rotación de llaves.
3. Caza IOC por Fleet; validación C2 en DNS/Proxy.
4. Post-incidente: Rule «Parent = nginx → bash» + Sigma para Sysmon/Linux-audit.

Errores frecuentes

Sobrecarga de ruido SIEM sin normalización y TTL.
Las detecciones sin mapeo en ATT&CK → «zonas ciegas».
Sin SOAR/enriquecimiento - MTTA largo, rutinas manuales.
Ignorar el comportamiento de UEBA es saltarse a los usuarios internos «lentos».
Las rígidas unidades TI globales sin TTL → cortan el tráfico empresarial.
No hay pruebas de regresión de las reglas.

Hoja de ruta de implementación

1. Inventario de registros y normalización (ECS/CEF), «conjunto mínimo».
2. Matriz de recubrimiento ATT&CK y detección básica de alto riesgo.
3. SLO y colas: P1-P4, on-call y escaladas.
4. SOAR playbucks: enriquecimiento, acción de contenido, bloques TTL.
5. UEBA y puntuación de riesgo: perfiles, anomalías, monitoreo a la deriva.
6. Purple Team/pruebas de niños: modo shadow, canarios, paquete de regresión.
7. Informes y cumplimiento: retiro, privacidad, dashboards de negocios.

Resultado

El SOC maduro es una telemetría completa + detección de calidad + disciplina de respuesta. Vincule las reglas a MITRE ATT&CK, automatice el enriquecimiento y el contenido en SOAR, mida el resultado con métricas SLO, verifique regularmente la cobertura en Purple Team, y su monitoreo será resistente al ruido, responda rápidamente a amenazas reales y mantenga métricas empresariales.