Ingeniería de detección: qué es y cómo se organiza un SOC

Para mucha gente, entrar en un SOC significa aprender a mirar una cola de alertas y decidir, una tras otra, si cada una es ruido o es un problema real. Ese trabajo tiene valor, pero no es el único que existe dentro de un centro de operaciones de seguridad, y tampoco es el que enseña este curso. Aquí el objetivo es otro: construir la alerta antes de que exista, decidir qué actividad merece vigilancia, activar la telemetría necesaria, escribirla como una regla documentada y comprobar que detecta lo que dice detectar.

Este primer módulo no analiza ningún ataque concreto. Fija el vocabulario, la plantilla de documentación y los criterios de calidad que se repiten en los quince módulos siguientes: cómo se organiza un SOC por niveles, qué convierte una detección en buena o en deuda pendiente, qué plantilla se usa para documentarla, dónde encaja MITRE ATT&CK hoy (que ya no es lo que era hace un año) y qué métricas merece la pena mirar.

Qué aprenderás

La diferencia real entre un analista N1 que hace triaje de alertas y un ingeniero de detección que las diseña, y qué hace cada nivel de un SOC (N1, N2, N3) con una alerta concreta.
Por qué la fatiga de alertas no es un problema de actitud individual sino un problema estructural del oficio, y qué lo produce.
El ciclo de vida completo de una detección, desde la hipótesis hasta su retirada, y por qué una detección sin dueño ni fecha de revisión es deuda técnica.
A rellenar una plantilla ADS (Alerting and Detection Strategy) de Palantir, sección por sección, con un ejemplo aplicado a una técnica real de ATT&CK.
Cómo usar MITRE ATT&CK v19 como sistema de referencia: tácticas, técnicas, subtécnicas, y el modelo de Detection Strategies y Analytics que sustituyó a los antiguos data sources.
La pirámide del dolor de David Bianco y por qué una detección de comportamiento le cuesta más al atacante que un hash o una IP.
Qué miden de verdad el MTTD y el MTTR, y qué se puede medir sin engañarte a ti mismo sobre la calidad de tu SOC.
Dónde queda documentado el ciclo de gestión de incidentes según NIST y qué referencia sobre gestión de logs, pese a citarse mucho, no está actualizada.
Dónde termina el trabajo de este curso y empieza el de un analista de respuesta a incidentes.

El analista que cierra alertas y el ingeniero que las diseña

La diferencia no está en el sueldo ni en el título del puesto, está en la dirección del trabajo. Un analista que hace triaje recibe una alerta ya escrita por otra persona y decide, con la información que tiene delante, si es un falso positivo, si necesita más contexto o si hay que escalarla. Un ingeniero de detección trabaja en la dirección contraria: parte de una idea sobre cómo se comporta un atacante, decide qué habría que observar para detectarlo, comprueba si esa observación es posible con la telemetría disponible y, si lo es, escribe la regla que algún día llegará a la pantalla del analista.

Los tres niveles clásicos de un SOC no son un escalafón jerárquico tanto como una división del tipo de trabajo cognitivo. El N1 vive en volumen: colas largas, turnos rotativos, un playbook por tipo de alerta y una decisión binaria (cerrar o escalar) tomada en minutos. El N2 investiga: correlaciona la alerta con otras fuentes, reconstruye una línea temporal, decide si hay incidente real y, si la regla generó ruido, pide que se ajuste. El N3 mira hacia delante: caza lo que ninguna regla detecta todavía (lo que en este curso llamamos threat hunting) y es quien escribe, prueba y mantiene las detecciones, con su nombre en la plantilla ADS como responsable.

Nivel	Qué hace con una alerta concreta	Foco del trabajo
N1 (triaje)	La recibe, sigue el playbook asociado, la cierra como falso positivo o la escala con el contexto mínimo requerido	Volumen y velocidad de respuesta
N2 (investigación)	Correlaciona con otras fuentes, decide si es un incidente real y solicita el ajuste de la regla si genera ruido	Contexto y decisión
N3 (hunting e ingeniería)	Busca comportamiento que ninguna regla cubre todavía, y escribe, prueba y es dueño de las detecciones nuevas	Diseño y mejora continua

Este reparto explica también por qué la fatiga de alertas no es un fallo de carácter de quien trabaja en N1. Cuando una regla mal calibrada genera cien alertas al día y noventa y ocho son ruido, la persona que las cierra aprende, con razón, a tratarlas con desconfianza. El problema no se arregla con más disciplina ni con turnos más cortos: se arregla subiendo la calidad de la fuente, es decir, escribiendo mejores detecciones desde el principio. Por eso un ingeniero de detección que no revisa nunca la tasa de cierre de sus reglas está trasladando su trabajo mal hecho al turno de noche de otra persona. Si quieres una descripción completa de las funciones diarias de un SOC (colas, herramientas, rotación de turnos), en cómo trabajar en un SOC lo cubrimos con más detalle del que cabe aquí.

El ciclo de vida de una detección: de la idea a la retirada

Una detección no nace escrita en Sigma ni en la sintaxis nativa de tu SIEM. Nace como una frase con forma de hipótesis: «si un atacante quisiera ejecutar código evitando las listas blancas de aplicaciones, podría abusar de regsvr32.exe para cargar un scriptlet remoto». A partir de ahí el ciclo tiene pasos concretos y, si te saltas alguno, se nota más adelante.

1. Idea o hipótesis

Sale de un informe de inteligencia, de un ejercicio de purple team, de una técnica de ATT&CK sin cobertura o de un incidente reciente. Conviene anotarla en una frase, no en una regla: todavía no sabes si la puedes construir.

2. Comprobar que hay telemetría que la sostiene

Antes de escribir nada hay que preguntarse si el dato que necesitas se genera, se recoge y llega a algún sitio consultable. Para el ejemplo de regsvr32, eso significa activar en Sysmon la creación de procesos (Event ID 1) y, opcionalmente, la carga de módulos (Event ID 7, que va desactivada por defecto porque genera mucho volumen). Un fragmento de configuración con ese propósito se ve así:

<Sysmon schemaversion="4.82">
  <EventFiltering>
    <RuleGroup name="regsvr32" groupRelation="or">
      <ProcessCreate onmatch="include">
        <Image condition="end with">regsvr32.exe</Image>
      </ProcessCreate>
      <ImageLoad onmatch="include">
        <Image condition="end with">regsvr32.exe</Image>
      </ImageLoad>
    </RuleGroup>
  </EventFiltering>
</Sysmon>

La sintaxis (schemaversion, RuleGroup, onmatch, la condición «end with») corresponde a la documentación oficial de Sysmon; este fragmento concreto lo construyo yo para el caso de regsvr32, no lo copio de ningún ejemplo publicado. El detalle de todos los tipos de evento de Sysmon y su configuración se cubre en el módulo 4 de este curso, aquí solo hace falta saber que sin este paso no hay detección posible, por buena que sea la idea.

Este mismo principio se aplica al transporte del dato. Si decides que necesitas también los eventos 4104 y 4103 de PowerShell (script block logging y module logging, que se escriben en el canal Microsoft-Windows-PowerShell/Operational), una suscripción de Windows Event Forwarding para recogerlos usa una consulta XPath como esta:

<QueryList>
  <Query Id="0" Path="Microsoft-Windows-PowerShell/Operational">
    <Select Path="Microsoft-Windows-PowerShell/Operational">*[System[(EventID=4104 or EventID=4103)]]</Select>
  </Query>
</QueryList>

La sintaxis de QueryList, Query y Select con filtro XPath está documentada por Microsoft en la referencia del comando wecutil. El transporte y la fiabilidad de esta tubería (agentes, syslog, qué pasa cuando un origen deja de enviar) tienen su propio módulo (el 5); aquí basta con verlo como un paso del ciclo que no se puede saltar. Sobre qué es un SIEM y qué papel cumple centralizando esta telemetría, tienes la introducción completa en qué es un SIEM.

3. Escritura

Se escribe la lógica de detección, normalmente en Sigma por su portabilidad entre motores, con nombres de campo que coincidan con lo que de verdad produce tu pipeline de normalización (más sobre esto en el módulo 6).

4. Prueba

Se ejecuta un test atómico contra un sistema de laboratorio y se comprueba que la regla dispara. Sin esto, una detección es una opinión sobre cómo debería comportarse el mundo, no un hecho comprobado.

5. Despliegue

Pasa de un repositorio de reglas a producción, idealmente por un proceso repetible (revisión por pares, validación de sintaxis, y solo entonces publicación), no copiando y pegando en la consola del SIEM a las tres de la tarde de un jueves.

6. Ajuste

Casi ninguna regla sale bien calibrada a la primera. El ajuste añade filtros para los falsos positivos reales que va generando ese entorno concreto, no los que se pueda imaginar quien la escribió.

7. Medición

Se registra cuánto dispara, qué proporción de esos disparos resulta accionable y si sigue cubriendo la técnica ATT&CK para la que se escribió.

8. Retirada

Una regla deja de tener sentido cuando la telemetría que la alimentaba desaparece, cuando el entorno cambia lo bastante como para que ya no aplique, o cuando otra detección más robusta la sustituye. Retirarla formalmente (y no dejarla viva y silenciada) es parte del trabajo, no un descuido.

El punto que quiero remarcar es este: una detección que nadie tiene asignada como propia, sin fecha marcada para revisarla, es deuda técnica desde el día en que se despliega, aunque funcione perfectamente ese primer día. Nadie revisa lo que no le pertenece, y una regla sin revisión periódica termina siendo o bien ruido que nadie se atreve a apagar, o bien una falsa sensación de cobertura sobre una técnica que el entorno cambió hace tiempo.

La plantilla ADS de Palantir, sección por sección

Documentar una detección con una frase en un ticket no es suficiente para que otra persona la mantenga dentro de seis meses. El marco Alerting and Detection Strategy (ADS), publicado por Palantir, propone una plantilla con nueve secciones fijas, pensada para que cualquier alerta que llegue a producción tenga la documentación mínima, esté validada y haya pasado por una revisión antes de desplegarse. Es de uso libre y su repositorio incluye ejemplos completos aplicados a técnicas reales.

Sección	Qué recoge
Goal	El objetivo de la detección en una frase: qué comportamiento adversario busca identificar.
Categorization	La técnica y subtécnica ATT&CK asociadas, para poder medir cobertura más adelante.
Strategy Abstract	Un resumen de alto nivel de la lógica de detección, sin entrar todavía en la sintaxis exacta.
Technical Context	Qué telemetría, campos y fuentes de datos hacen falta, y por qué esos y no otros.
Blind Spots and Assumptions	Qué variantes del comportamiento NO detecta esta regla, y qué se está dando por hecho sobre el entorno.
False Positives	Qué actividad legítima puede parecerse a la maliciosa y disparar la regla sin motivo.
Validation	Cómo se comprueba, con un test reproducible, que la regla detecta lo que dice detectar.
Priority	La severidad y urgencia con la que debe tratarse una coincidencia.
Response	Los pasos que debe seguir quien reciba la alerta al confirmarla.

Aplicado a un caso concreto, T1218.010 (System Binary Proxy Execution: Regsvr32, una subtécnica que hoy vive bajo la táctica Stealth de ATT&CK, como se explica en la siguiente sección), el ejercicio de rellenar la plantilla obliga a ser específico en cada apartado. El Goal no es «detectar regsvr32 malicioso» sino algo más cercano a «detectar el uso de regsvr32.exe para registrar o ejecutar una DLL o un scriptlet alojado en un servidor remoto, evitando controles de lista blanca de aplicaciones». La Categorization apunta a T1218.010 dentro de Stealth. El Technical Context exige el campo de línea de comandos del proceso, no solo su nombre, porque la actividad maliciosa depende de los parámetros (/i o /u apuntando a una URL) y no del binario en sí, que es completamente legítimo. Los Blind Spots incluyen, como mínimo, que un atacante que renombre el ejecutable o que use la ruta completa sin el nombre «regsvr32.exe» al final no coincidirá con una regla que solo mire el nombre de imagen. Los False Positives previsibles incluyen instaladores legítimos de software que registran componentes COM contra rutas de red internas, algo habitual en entornos con reparto de aplicaciones por recurso compartido.

Rellenar cada sección con este nivel de concreción es exactamente lo que se pide en el ejercicio de laboratorio de este módulo, aplicado a una detección de tu elección.

MITRE ATT&CK como sistema de referencia del curso

ATT&CK organiza el comportamiento adversario en tres niveles de detalle. Una táctica es el objetivo que persigue el atacante en un momento dado (moverse lateralmente, mantener persistencia, evadir defensas). Una técnica es el método concreto para lograr ese objetivo (por ejemplo, T1218, abuso de binarios firmados del sistema operativo como proxy de ejecución). Una subtécnica es una variante más específica de esa técnica (T1218.010, el abuso concreto de regsvr32.exe dentro de esa familia).

El cambio de v19: Stealth y Defense Impairment

Este curso fija como referencia la versión v19 de MITRE ATT&CK, publicada el 28 de abril de 2026, según la propia página de actualizaciones del proyecto. El cambio estructural más importante de esa versión, y el que invalida cualquier material que hable de «las catorce tácticas de Enterprise ATT&CK», es la división de la antigua táctica Defense Evasion en dos tácticas nuevas: Stealth (que conserva el identificador TA0005) y Defense Impairment (con el identificador nuevo TA0112). Según explican los propios responsables del proyecto, la mayoría de las técnicas que antes vivían bajo Defense Evasion aterrizaron en Stealth o en Defense Impairment, y un número pequeño salió de ese espacio por completo hacia otras tácticas. Enterprise ATT&CK tiene hoy quince tácticas, no catorce.

La distinción entre ambas no es cosmética. Stealth agrupa el comportamiento que busca pasar desapercibido dentro de actividad legítima (como el propio T1218.010, camuflar la ejecución maliciosa detrás de un binario firmado de Windows). Defense Impairment agrupa lo contrario: acciones que deshabilitan, degradan o manipulan directamente un control de seguridad, como desactivar el registro de eventos o detener un servicio antivirus. Cualquier mapeo de reglas o cuadros de mando hecho antes de abril de 2026 que etiquete algo como «Defense Evasion» sigue funcionando técnicamente si usaba el identificador TA0005 (porque ese identificador ahora corresponde a Stealth), pero el significado semántico del campo ha cambiado, y conviene revisar cada mapeo caso por caso en vez de asumir que sigue siendo correcto. De hecho, la regla Sigma que se usa como ejemplo en la sección siguiente de este módulo está etiquetada como attack.defense_evasion porque se escribió en 2023, antes del cambio: es un ejemplo real de por qué hay que revisar las etiquetas antiguas, no solo confiar en ellas.

De los data sources a las Detection Strategies y los Analytics

El propio ATT&CK cambió también cómo describe la telemetría necesaria para detectar cada técnica, y esto afecta directamente a lo que se trabajará en el módulo 8. Hasta la versión v17, cada técnica enlazaba con una lista de «data sources» (categorías amplias como Process o Command) y sus «data components» asociados. En la versión v18, publicada el 28 de octubre de 2025, MITRE dio de baja el catálogo de data sources (39 en Enterprise, 6 en Mobile y 16 en ICS quedaron marcados como obsoletos) y lo sustituyó por un modelo de dos capas: Detection Strategies, que describen el enfoque defensivo de alto nivel para una técnica, y Analytics, implementaciones concretas de esa estrategia ligadas a una plataforma y unos campos de telemetría específicos. Los data components no desaparecieron, se reescribieron (pasaron de una numeración de versión 1.x a la 2.0) y ahora cuelgan de los Analytics dentro de cada Detection Strategy, no de un data source independiente.

Para dar una idea de la escala del catálogo actual: según la propia página de actualizaciones de abril de 2026, el dominio Enterprise de ATT&CK v19 contiene 15 tácticas, 222 técnicas, 475 subtécnicas, 697 Detection Strategies, 1758 Analytics y 106 data components. Para T1218.010 en concreto, la Detection Strategy asociada es DET0282, con la Analytic AN0785, centrada en identificar ejecuciones anómalas de regsvr32.exe (rutas inusuales, argumentos /i o /u sobre referencias sospechosas, o conexiones de red iniciadas por el propio proceso). El módulo 8 de este curso trabaja con este modelo de dos capas al construir un caso de uso a partir de una técnica; aquí basta con saber que existe y que sustituyó al modelo anterior. La guía general de ATT&CK, explicado desde cero, está en la guía de MITRE ATT&CK del blog; aquí lo usamos ya como herramienta de trabajo diaria.

La pirámide del dolor: por qué un hash no duele y un TTP sí

David Bianco publicó en 2013 en su blog personal la pirámide del dolor, un modelo que sigue siendo la referencia habitual para explicar por qué unos indicadores de compromiso valen más que otros a la hora de escribir una detección. La idea central es simple: cuanto más arriba está un indicador en la pirámide, más le cuesta al atacante cambiarlo para evitar que lo detectes.

Nivel (de abajo arriba)	Ejemplo	Coste para el atacante de esquivarlo
Hash values	SHA1 o MD5 de un binario concreto	Trivial: recompilar el binario cambia el hash
IP addresses	Dirección IP de un servidor de mando y control	Bajo: cambiar de host o de proxy
Domain names	Dominio usado para C2 o para alojar el payload	Medio: registrar otro dominio cuesta tiempo y dinero, pero es factible
Network / host artifacts	Un patrón de User-Agent, una ruta de fichero, un valor de registro característico	Considerable: obliga a rediseñar parte de la herramienta
Tools	El propio malware o la utilidad usada para el ataque	Alto: hay que sustituir o reescribir la herramienta entera
TTPs	El comportamiento completo, por ejemplo usar regsvr32.exe para cargar un scriptlet remoto en vez de un ejecutable	Máximo: obliga a cambiar de método de ataque

Una regla que bloquea un hash concreto se vuelve inútil en cuanto el atacante recompila el binario, algo que a menudo cuesta segundos. Una regla que detecta el patrón de comportamiento (regsvr32.exe con el argumento /i apuntando a una URL remota, con independencia del hash del payload que descargue) sigue funcionando aunque el atacante cambie de herramienta, porque lo que detecta no es «este fichero» sino «esta forma de operar». Por eso una detección basada en TTP tiene mucha más vida útil que una basada en indicadores atómicos, aunque escribirla sea más difícil y, casi siempre, requiera entender mejor el comportamiento que se quiere cazar.

Sigma como lengua común y su despliegue

Sigma es un formato abierto para escribir reglas de detección en YAML de forma independiente del motor donde acabarán ejecutándose. El módulo 7 de este curso entra en su sintaxis completa; aquí interesa como pieza del ciclo de vida: es lo que normalmente se escribe en el paso 3 y se convierte en la consulta nativa de tu SIEM en el paso de despliegue.

Un ejemplo real, tomado del repositorio principal de reglas y firmado por su autor original, detecta precisamente el patrón de regsvr32 que venimos usando de ejemplo:

title: Potentially Suspicious Regsvr32 HTTP/FTP Pattern
id: 867356ee-9352-41c9-a8f2-1be690d78216
status: experimental
description: Detects regsvr32 execution to download/install/register new DLLs that are hosted on Web or FTP servers.
author: Florian Roth (Nextron Systems)
date: 2023/05/24
modified: 2023/05/26
tags:
    - attack.defense_evasion
    - attack.t1218.010
logsource:
    category: process_creation
    product: windows
detection:
    selection_img:
        - Image|endswith: 'regsvr32.exe'
        - OriginalFileName: 'REGSVR32.EXE'
    selection_flag:
        CommandLine|contains:
            - ' /i'
            - ' -i'
    selection_protocol:
        CommandLine|contains:
            - 'ftp'
            - 'http'
    condition: all of selection_*
falsepositives:
    - Unknown
level: medium

Esta regla está tomada de un fichero público del repositorio de SigmaHQ, autoría de Florian Roth (Nextron Systems). La licencia bajo la que se publican las reglas del repositorio es la Detection Rule License (DRL) 1.1, muy permisiva: permite uso privado y comercial siempre que se cite al autor de la regla, requisito que se extiende también a cualquier vista de producto que muestre coincidencias generadas por esa regla, no solo a la reproducción del texto de la regla en sí.

Para convertir una regla Sigma al lenguaje de consulta de tu backend se usa la herramienta oficial de línea de comandos, que se instala como paquete de Python:

pip install sigma-cli
sigma plugin install splunk
sigma convert -t splunk -p sysmon rules/windows/process_creation/proc_creation_win_regsvr32_network_pattern.yml

El módulo 15 de este curso cubre el «detection-as-code» completo (reglas versionadas en git, revisión por pares, pruebas automáticas y despliegue con posibilidad de deshacer un cambio). Aquí basta con ver la forma general que toma un paso de validación de sintaxis dentro de un pipeline de integración continua, a título orientativo:

name: validar-reglas
on: [pull_request]
jobs:
  check-sigma:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: pip install sigma-cli
      - run: sigma check rules/

Escribir una regla no es lo mismo que probarla. Para el paso 4 del ciclo de vida (la prueba) se usa un framework de ataque atómico como Atomic Red Team, publicado por Red Canary bajo licencia MIT, que ejecuta acciones concretas mapeadas a técnicas de ATT&CK sobre un sistema de laboratorio. La instalación y la ejecución de un test contra T1218.010 se hacen así:

IEX (IWR 'https://raw.githubusercontent.com/redcanaryco/invoke-atomicredteam/master/install-atomicredteam.ps1' -UseBasicParsing);
Install-AtomicRedTeam -getAtomics

Invoke-AtomicTest T1218.010 -TestNumbers 1,2

El primer bloque instala el módulo de PowerShell Invoke-AtomicRedTeam y descarga la carpeta de tests. El segundo ejecuta los tests numerados 1 y 2 de la técnica T1218.010 contra el equipo local. Ejecutar estos tests puede dejar el sistema en un estado no deseado (así lo advierte el propio proyecto), así que solo deben lanzarse en una máquina de laboratorio, nunca en producción.

Sobre licencias, para no repetir el error de tratarlas todas igual: los contenidos de detección de Splunk (security_content) se publican bajo Apache-2.0; Atomic Red Team, bajo MIT; el dataset BOTSv3 de Splunk, bajo CC0 (dominio público); las reglas de detection-rules de Elastic se publican bajo Elastic License v2, lo que en la práctica significa que se pueden citar y enlazar pero no reempaquetar como si fueran de licencia libre. Y los CIS Benchmarks son gratuitos únicamente para uso no comercial (licencia Creative Commons BY-NC-SA), así que aquí se explican pero no se reproducen sus tablas de controles.

Métricas con honestidad

El MTTD (tiempo medio de detección) mide cuánto pasa entre que ocurre una actividad y el SOC genera una alerta sobre ella. El MTTR (tiempo medio de respuesta, a veces de resolución según cómo lo defina cada organización) mide cuánto pasa entre esa alerta y el cierre del caso. Los dos son útiles, y los dos se pueden manipular sin que nadie mienta explícitamente: basta con escribir reglas más laxas que disparen antes (bajando el MTTD a costa de más ruido) o con cerrar casos con menos investigación (bajando el MTTR a costa de calidad de la respuesta).

El número absoluto de alertas generadas por un SOC no dice nada sobre su calidad. Un SOC que genera diez mil alertas al mes y cierra el noventa y cinco por ciento sin investigación real no está mejor protegido que uno que genera quinientas y las revisa todas a fondo; probablemente está peor, porque el volumen esconde los verdaderos positivos entre el ruido. Lo mismo pasa con el número de reglas desplegadas: tener trescientas detecciones no vale nada si la mitad apunta a la misma técnica y la otra mitad nunca ha disparado porque la telemetría que necesitan no llega.

Lo que sí se puede medir sin engañarte: la cobertura de técnicas ATT&CK con telemetría real (no cuántas reglas existen, sino cuántas técnicas tienen al menos una fuente de datos que realmente llega al SIEM y una regla que la consulta), el ratio de alertas accionables sobre el total (cuántas de las alertas cerradas terminaron con alguna acción real, aunque sea documentar y ajustar la regla) y el tiempo hasta el primer análisis humano de una alerta nueva, que es un indicador honesto de si tu cola de trabajo está desbordada. Ninguna de estas tres sustituye a las otras dos: hay que mirarlas juntas.

Marco documental: dónde vive esto en NIST

Para situar la detección dentro de un ciclo de gestión de incidentes más amplio, la referencia vigente es la NIST SP 800-61 Rev.3, publicada en abril de 2025, con el título «Incident Response Recommendations and Considerations for Cybersecurity Risk Management: A CSF 2.0 Community Profile». Esta revisión sustituye a la Rev.2 (de 2012) y cambia de enfoque: en vez de tratar la respuesta a incidentes como un proceso aislado, la integra dentro del ciclo de gestión de riesgo del NIST Cybersecurity Framework 2.0. El detalle del ciclo de respuesta propiamente dicho (preparación, contención, erradicación, recuperación) pertenece al curso de DFIR; aquí interesa sobre todo saber dónde termina la detección y empieza esa fase, algo que se trata en la última sección de este módulo.

Hay una referencia que se cita constantemente en artículos sobre gestión de logs y que conviene usar con cuidado: la NIST SP 800-92, «Guide to Computer Security Log Management», es de septiembre de 2006. No es un documento actualizado ni refleja las prácticas actuales de recolección centralizada, y su intento de sustitución (la Revisión 1, renombrada «Cybersecurity Log Management Planning Guide») sigue en estado de borrador inicial para comentarios (initial public draft), publicado en octubre de 2023 con el periodo de comentarios ya cerrado desde noviembre de ese año, sin que se haya publicado una versión final. Citar el 800-92 como si fuera una guía vigente sobre cómo gestionar logs hoy es un error de fecha, aunque siga siendo un documento de referencia histórica razonable sobre los principios generales del problema.

Dónde termina este módulo: la frontera con el DFIR

El trabajo que describe este curso acaba en el momento en que una alerta se confirma como incidente real. Hasta ahí, la responsabilidad es fabricar la detección, ajustarla, y entregarla con contexto suficiente para que se tome una decisión rápida. A partir de ahí (contener el equipo afectado, preservar evidencia, reconstruir la cadena de ataque, coordinar la comunicación) el trabajo pasa a manos del equipo de respuesta a incidentes, con herramientas, plazos legales y un proceso distintos que se cubren en profundidad en el curso de DFIR. Los criterios formales de ese traspaso (a quién se avisa, con qué información, y qué plantilla de traspaso se usa) se ven con detalle en el último módulo de este curso, el 16.

Ejercicio: escribe una ADS completa

Elige una detección sencilla que puedas validar con software gratuito. Si no tienes una idea propia, puedes seguir el hilo usado en este módulo: T1218.010, abuso de regsvr32.exe para cargar código remoto.

Instala Sysmon en una máquina Windows de laboratorio (una máquina virtual desechable, nunca tu equipo de trabajo) con una configuración que capture como mínimo la creación de procesos.
Instala Invoke-AtomicRedTeam siguiendo los comandos de la sección anterior y descarga la carpeta de tests atómicos.
Ejecuta Invoke-AtomicTest T1218.010 y observa en el Visor de eventos, dentro de Applications and Services LogsMicrosoftWindowsSysmonOperational, el evento de creación de proceso que genera. Verifica en tu propio entorno los campos que aparecen (esto no se puede dar por hecho de memoria, cada versión de Sysmon y cada configuración puede variar ligeramente el detalle capturado).
Compara lo que observas con la regla Sigma citada en este módulo y con las muestras ya grabadas del repositorio público EVTX-ATTACK-SAMPLES (carpeta de Defense Evasion, ficheros relacionados con la ejecución de scriptlets vía regsvr32/scrobj.dll), publicado bajo licencia GPL-3.0.
Rellena las nueve secciones de la plantilla ADS de Palantir para esta detección. Presta especial atención a Blind Spots and Assumptions (qué variantes no detectarías: nombre de proceso renombrado, ruta completa sin coincidir con el patrón, ejecución remota vía WMI en vez de línea de comandos local) y a False Positives (qué actividad legítima de tu propio entorno, no de un entorno genérico, podría disparar la regla).
Si quieres practicar con más volumen de telemetría ya grabada antes de escribir tus propias reglas, el repositorio Security-Datasets (licencia MIT) y el dataset BOTSv3 de Splunk (licencia CC0) son dos fuentes públicas adicionales pensadas exactamente para esto.

No inventes cifras de falsos positivos ni afirmes que tu regla «detecta» una técnica en general: documenta lo que observaste en tu laboratorio concreto y marca como pendiente de verificación cualquier cosa que no hayas comprobado tú mismo.

Preguntas frecuentes

¿Hace falta saber programar para trabajar como ingeniero de detección?

Hace falta manejarse con soltura en línea de comandos de Windows y Linux, y entender la sintaxis de formatos como YAML (que usa Sigma) y XML (que usa la configuración de Sysmon y las suscripciones de Windows Event Forwarding). Programar en el sentido de desarrollar software no es obligatorio para escribir detecciones, aunque sí ayuda mucho cuando se llega al despliegue por CI/CD del módulo 15.

¿Sigma sustituye a las reglas nativas de mi SIEM?

No directamente: Sigma es un formato intermedio que se convierte a la sintaxis nativa de cada backend (Splunk, Elastic, Microsoft Sentinel, y otros) mediante herramientas como sigma-cli. Se escribe una vez en Sigma y se despliega en el motor que corresponda, lo que facilita portar detecciones si algún día cambias de SIEM.

¿Qué pasa si un ADS pide una telemetría que mi organización no recoge?

Esa es precisamente la razón de existir del paso 2 del ciclo de vida de una detección. Si la telemetría no existe, la detección no se puede escribir todavía: el trabajo pasa a activar esa fuente de datos primero (lo que se cubre en los módulos 3, 4 y 5) o a documentar el hueco como una limitación conocida en el apartado Blind Spots del ADS, no a fingir que la detección funciona.

¿Cuántas alertas por analista se consideran demasiadas?

No hay una cifra universal honesta que dar aquí, porque depende del tipo de alerta, de cuánto contexto trae ya incluido y de la experiencia del equipo. Lo que sí es una señal fiable de que hay un problema es que el tiempo hasta el primer análisis humano de una alerta nueva empiece a crecer de forma sostenida, con independencia del número absoluto.

¿Dónde entra el threat hunting en todo este ciclo?

El threat hunting es lo que alimenta el paso 1 (idea o hipótesis) cuando no viene de un informe externo. Un analista de N3 que busca de forma proactiva comportamiento que ninguna regla cubre todavía, y que encuentra algo real, acaba de generar la hipótesis de la que nacerá una detección nueva. Por eso hunting e ingeniería de detección suelen ser la misma función en equipos pequeños.

¿Necesito un SIEM comercial para practicar lo de este curso?

No. El módulo 2 monta un laboratorio completo con herramientas gratuitas (Wazuh, Security Onion, o la versión libre de Splunk) y datasets ya grabados como los citados en el ejercicio de este módulo, así que puedes seguir todo el curso sin gastar en licencias.

Módulo 1: Qué es la ingeniería de detección y cómo se organiza un SOC