Módulo 16: Cierre operativo y traspaso a respuesta a incidentes

Una alerta confirmada no termina cuando el analista decide que es real. Empieza otra fase, con reglas propias, que no aparecen en ninguna condición Sigma: hay que decidir si eso que se está mirando pasa el umbral de incidente, documentar lo que se sabe y lo que no, avisar con el detalle correcto a quien recibe el testigo y, si al final resulta que no era nada, cerrar el caso de forma que ese «no era nada» deje algo útil detrás. El módulo 1 de este curso prometió que los criterios formales de ese traspaso se verían aquí, al final; este es ese módulo.

No hay ninguna regla nueva de detección en las páginas que siguen. Lo que hay es la parte operativa que sostiene todo lo anterior: cómo se organiza una cola de trabajo para que no se convierta en un vertedero, cómo se calcula cuánto urge una alerta en vez de solo cuánto pesa su severidad, qué preguntas hace un analista en los primeros minutos, cuándo una alerta cruza la línea hacia incidente, qué lleva un traspaso formal al equipo de respuesta, cómo se comparte esa información sin regalarla a quien no debería tenerla y qué informe mensual convierte el trabajo del SOC en algo que alguien, de verdad, se lee.

Qué aprenderás

• Cómo se organizan las colas de alertas por severidad y por origen, y qué política de caducidad evita que una cola se convierta en un cementerio de casos sin cerrar.
• La diferencia real entre severidad y prioridad, y cómo se combinan la severidad de la regla, la criticidad del activo y la identidad implicada en una sola urgencia con la que trabajar.
• Qué preguntas hace un analista en los primeros minutos de triaje y qué enriquecimiento automático (inventario, dueño del activo, reputación, contexto de identidad) ahorra tiempo de verdad.
• Por qué el analista necesita el evento crudo delante, no solo el resumen que genera la regla o la consola del SIEM.
• Los criterios explícitos que convierten una alerta en incidente, escritos antes de que suene la primera alerta, y dónde continúa el trabajo a partir de ese momento.
• A redactar un traspaso formal completo: línea de tiempo con huso horario declarado, activos e identidades implicadas, origen de la evidencia y un apartado explícito de lo que todavía no se ha comprobado.
• El marco TLP 2.0 de FIRST, sus etiquetas exactas y qué se puede compartir con quién sin tener que inventarse un criterio cada vez.
• A cerrar un falso positivo de forma que alimente el ajuste de reglas, y qué apartados hacen que un informe mensual del SOC se lea de verdad, con los puntos ciegos conocidos incluidos.

La cola de alertas como sistema

Una cola de alertas no es un almacén neutro donde esperan turno los casos. Es la unidad de trabajo real de un SOC, y cómo está organizada determina, más que cualquier regla suelta, qué se atiende a tiempo y qué se pudre sin que nadie lo note. La primera decisión de diseño es si hay una cola única, ordenada por severidad, o varias colas separadas por origen (una para alertas de EDR, otra para red, otra para nube, otra para identidad). Una cola única es más simple de vigilar pero mezcla trabajo que exige habilidades distintas: quien es bueno leyendo una línea de comandos de PowerShell ofuscada no tiene por qué ser quien mejor interpreta una alerta de tráfico de red sospechoso. Colas separadas por origen permiten asignar por especialidad, a costa de que alguien tenga que vigilar que ninguna de esas colas crezca sin control mientras las demás respiran.

La asignación dentro de cada cola sigue, en general, uno de tres modelos: reparto por turno (round robin, cada alerta nueva va al siguiente analista disponible, sin mirar de qué trata), reparto por especialidad (una alerta de movimiento lateral va a quien tiene más horas hechas en identidad y Active Directory, una de red a quien vive en Suricata y Zeek) o modelo de extracción, donde el propio analista toma la siguiente alerta de la cola cuando termina la anterior, en vez de que se le asigne. Ninguno de los tres es superior en abstracto: el reparto por turno reparte la carga con justicia pero ignora la aptitud, el reparto por especialidad hace mejor uso del talento disponible pero puede dejar colas enteras esperando a que la única persona experta en ese origen llegue de vacaciones, y el modelo de extracción da autonomía al analista a costa de que nadie fuerza a nadie a tocar lo más urgente si decide no hacerlo.

Lo que de verdad separa una cola sana de una que se pudre no es el modelo de asignación, es la política de caducidad. Una alerta que lleva cuarenta y ocho horas sin que nadie la mire tiene un coste que va más allá del trabajo pendiente que acumula: en el caso de una detección de endpoint, el proceso que la generó ya no existe en memoria, el usuario ha apagado y encendido la máquina dos veces y cualquier evidencia volátil que hubiera merecido preservarse desapareció mientras la alerta esperaba turno. Sin un límite explícito (una alerta crítica que lleva más de una hora sin asignar dispara una escalada automática al responsable de turno; una de severidad media que lleva más de un día se marca para revisión de por qué nadie la ha tocado) la cola no acumula trabajo, acumula pruebas caducadas con forma de ticket abierto. He visto colas con miles de casos «pendientes» que en realidad eran, todos, casos muertos: nadie los iba a mirar nunca, pero tampoco nadie se atrevía a cerrarlos sin revisarlos uno a uno, así que se quedaban ahí, inflando cualquier métrica de volumen y escondiendo, entre el ruido, los pocos que sí importaban.

Severidad y prioridad no son lo mismo

La severidad es una propiedad de la regla, fijada por quien la escribió: describe qué tan grave sería el comportamiento que detecta, si de verdad ocurre, con independencia de dónde ocurra. La prioridad (o la urgencia, según el nombre que use tu SIEM) es otra cosa: depende de qué toca esa alerta en concreto. Una regla de severidad media que dispara sobre un controlador de dominio pesa más, en la práctica, que una regla de severidad alta que dispara sobre una máquina de pruebas que se va a reformatear mañana. Confundir las dos cosas, y ordenar la cola solo por la severidad fija de la regla, es la forma más habitual de que un SOC entierre lo importante debajo de lo simplemente ruidoso.

La sección Priority de la propia plantilla ADS de Palantir que se trabajó en el módulo 1 ya apuntaba a esto: «la severidad y la urgencia con la que debe tratarse una coincidencia» son dos ingredientes, no uno. Un ejemplo real y documentado de cómo se calcula esa combinación es el de Splunk Enterprise Security, que asigna una «urgencia» a cada evento notable combinando la severidad definida en la búsqueda de correlación con la prioridad que el propio SOC ha asignado, en su marco de activos e identidades, al equipo o a la cuenta implicada. La urgencia no depende solo de la severidad de la regla, depende de qué toca, y esa es precisamente la idea que conviene llevarse de este ejemplo aunque tu SIEM calcule la combinación de otra forma.

Severidad de la alerta	Prioridad del activo o la identidad	Urgencia resultante
Informativa	Cualquiera	Informativa
Baja o media	Baja o desconocida	Baja
Alta	Baja o desconocida	Media
Crítica	Baja o desconocida	Alta
Media	Media	Media
Alta	Media	Alta
Crítica	Media	Crítica
Baja	Crítica	Media
Alta o crítica	Crítica	Crítica

(Tabla adaptada, simplificando las combinaciones a las más habituales, de la lógica documentada por Splunk para el cálculo de urgencia de eventos notables en Enterprise Security: la prioridad se toma del campo de mayor rango entre el activo y la identidad implicados cuando ambos están presentes en el mismo evento.)

Para que esta combinación funcione hace falta un dato que muchos SOC dan por hecho sin tenerlo: quién es el dueño de cada activo y qué criticidad tiene, y qué identidades son privilegiadas frente a cuentas de servicio o de usuario normal. Sin ese inventario, la columna «prioridad del activo» de la tabla de arriba está vacía siempre, y toda alerta termina con la urgencia que le daría su severidad en solitario, que es exactamente el problema que se quería evitar. El módulo 10 de este curso ya trabajó cómo distinguir una cuenta de servicio de una humana por su línea base de comportamiento; ese mismo trabajo de caracterización es el que alimenta, aquí, la mitad «identidad» de la ecuación de prioridad.

Triaje en la práctica: los primeros minutos

Cuando una alerta cae en la bandeja de un analista, las primeras preguntas no son sobre la técnica de ataque, son sobre el contexto que la rodea. ¿Es la primera vez que este activo o esta identidad disparan esta regla, o hay un historial que ya se revisó y se descartó? ¿Hay otra alerta, de otra regla o de otro origen, en una ventana de tiempo cercana, sobre el mismo activo o la misma identidad? ¿A qué unidad de negocio pertenece el activo, y esa unidad tiene algo especialmente sensible que la convierte en objetivo más probable que la media? ¿La cuenta implicada es de una persona, de un servicio o de un proceso de automatización, y ese detalle cambia lo que sería comportamiento normal?

Contestar todo esto a mano, alerta por alerta, es el trabajo que se traga el tiempo de un analista de N1. El enriquecimiento automático existe precisamente para no repetir esa investigación desde cero cada vez: un lookup contra el inventario de activos (CMDB o equivalente) que añade el dueño y la criticidad sin que nadie tenga que preguntarlo por chat; un lookup de reputación contra la IP, el dominio o el hash implicados, que no dice «esto es malo» (ninguna de esas fuentes sustituye el juicio del analista) pero sí ahorra la búsqueda manual; y un lookup contra el directorio de identidad que trae de serie los grupos a los que pertenece la cuenta, si es una cuenta privilegiada y si acaba de sufrir algún cambio relevante, como un restablecimiento de contraseña. Cuando ese enriquecimiento llega ya pegado a la alerta, en vez de tener que ir a buscarlo, el tiempo hasta la primera decisión baja de forma real, no cosmética.

Nada de este enriquecimiento sustituye mirar el evento tal como llegó al SIEM. El resumen que muestra la consola (el título de la alerta, la frase que describe qué detecta la regla) es una compresión escrita por quien redactó esa regla, en un momento dado, con unos supuestos sobre el entorno que pueden haber caducado sin que nadie lo note: un campo que cambió de nombre tras una actualización del agente, un valor que ya no aparece exactamente igual. El módulo 14 de este curso insistió en lo mismo aplicado a la validación de una regla; aquí la misma disciplina se aplica al triaje del día a día, con la urgencia añadida de que una decisión de cerrar o escalar mal tomada por confiar ciegamente en el resumen tiene consecuencias inmediatas, no solo una detección peor calibrada. Extraer el evento crudo de un canal concreto, filtrado por su identificador, es una orden de una sola línea:

wevtutil qe Security /q:"*[System[(EventID=4720)]]" /f:text /c:5

Esta sintaxis usa el mismo formato de consulta XPath que ya se vio en el módulo 1 para las suscripciones de Windows Event Forwarding, aplicado aquí a una consulta local con wevtutil qe (query-events), documentada por Microsoft junto al resto de comandos de wevtutil. El modificador /f:text imprime el evento en texto plano en vez de XML, y /c:5 limita la salida a los cinco resultados más recientes. Qué campos exactos aparecen y con qué valores depende por completo de tu entorno: verifícalo contra tu propio Visor de eventos o tu propio SIEM, nunca contra lo que diga cualquier texto sobre lo que «debería» aparecer.

Criterios de escalado: de alerta a incidente

NIST define un evento, en el vocabulario de la revisión más reciente de su guía de respuesta a incidentes, como «cualquier suceso observable que involucre activos informáticos, incluidas plataformas físicas y virtuales, redes, servicios y entornos en la nube». Un incidente, en la misma familia de publicaciones, es algo más concreto: un suceso que compromete real o inminentemente, sin autorización legal, la integridad, confidencialidad o disponibilidad de información o de un sistema de información, o que supone una violación o amenaza inminente de violación de una ley, política o procedimiento de seguridad. La diferencia no es de grado, es de naturaleza: todo incidente parte de uno o varios eventos, pero no todo evento (ni siquiera todo evento sospechoso) llega a ser un incidente.

El error habitual es dejar esa frontera para que la trace, en caliente, quien esté de guardia esa noche. Cuando eso pasa, dos analistas igual de competentes toman decisiones distintas ante la misma alerta, no porque uno sepa menos que el otro, sino porque cada uno aplica su propio criterio no escrito. Los criterios de escalado tienen que existir antes de que suene la primera alerta a la que se les va a aplicar, en un documento que cualquiera del equipo pueda consultar, con ejemplos concretos, no solo con principios abstractos. Algunos ejemplos de criterio explícito, del tipo que sí funciona en un documento real: cualquier alerta que alcance urgencia crítica según la matriz de la sección anterior se escala sin esperar confirmación completa; cualquier evidencia de acceso con credenciales privilegiadas fuera del horario o del origen habitual de esa cuenta se escala aunque la severidad de la regla individual sea baja; cualquier indicio de exfiltración de datos, confirmado o no, se escala de inmediato por el coste de esperar; dos alertas de severidad media sobre el mismo activo en menos de una hora se tratan como una sola señal de mayor peso, no como dos casos independientes.

A partir del momento en que una alerta cruza ese umbral escrito, el trabajo que describe este curso (fabricar, ajustar y hacer sonar la detección) da paso a otro con herramientas, plazos y un proceso propio: contener el activo afectado, preservar evidencia siguiendo una cadena de custodia, reconstruir la secuencia completa del ataque, coordinar la comunicación con quien tenga que tomar decisiones de negocio. Ese proceso, con su ciclo PICERL completo, es exactamente lo que cubre el curso de DFIR de este mismo centro. Lo único que hace falta saber aquí es dónde termina limpiamente el trabajo de detección y empieza el de respuesta, y qué se entrega en ese punto exacto, que es el tema de la siguiente sección.

El traspaso formal al equipo de respuesta

Un traspaso mal hecho obliga al equipo de DFIR a repetir, desde cero, buena parte del trabajo que el SOC ya había hecho, con la diferencia de que ahora lo hacen bajo presión y con menos contexto fresco que quien detectó la alerta originalmente. Un traspaso bien hecho trae, como mínimo, cinco piezas.

La primera es una línea de tiempo con marcas de tiempo en un huso horario declarado explícitamente, no asumido. Un huso horario sin declarar convierte cualquier línea de tiempo en una fuente de errores: distintas herramientas muestran la misma marca de tiempo en huso local o en UTC según cómo estén configuradas, y un equipo de respuesta que trabaje con evidencia de varios orígenes (el SIEM en un huso, un log exportado a mano en otro, el reloj del propio analista en un tercero) puede reconstruir una secuencia de eventos que en realidad nunca ocurrió en ese orden. La recomendación más simple, y la que evita la mayoría de estos errores, es fijar UTC como huso de referencia del traspaso y anotarlo una sola vez al principio del documento, no en cada línea.

La segunda son los activos y las identidades implicados, con su criticidad y su dueño ya resueltos (el mismo enriquecimiento del triaje, ahora consolidado en el documento de traspaso en vez de disperso en la consola del SIEM). La tercera es la evidencia de origen: de dónde sale cada dato citado en la línea de tiempo y dónde está guardado ahora mismo, con ruta exacta, no «en el SIEM» sin más precisión.

La cuarta pieza es la que más se salta, y es tan importante como la que sí se comprobó: qué se ha verificado y qué no. Lo que no se ha comprobado pesa tanto como lo que sí, siempre que se diga con la misma claridad. Un traspaso que solo enumera hechos confirmados y calla sobre el resto deja al equipo de respuesta sin saber si un hueco en la historia es un hueco real (nadie lo ha mirado todavía) o una ausencia deliberada (se miró y no había nada). Escribir «no se ha comprobado si hubo movimiento lateral posterior a este equipo» no es una admisión de fracaso, es información operativa de la misma categoría que cualquier hecho confirmado, y evita que el equipo de respuesta pierda tiempo asumiendo que algo ya se descartó cuando en realidad nadie llegó a mirarlo.

La quinta son las acciones de contención que ya se han tomado, con hora y con quién las ejecutó: una cuenta deshabilitada, un equipo aislado de red, una regla de bloqueo añadida en el perímetro. Sin este apartado, el equipo de respuesta puede duplicar una acción ya hecha o, peor, asumir que algo está contenido cuando en realidad nadie llegó a ejecutar esa orden. Un esqueleto razonable de las cinco piezas, adaptable a cualquier formato de ticket o documento, es este:

Caso: <identificador interno>
Regla / alerta origen: <nombre o id de la regla que disparo>
Analista que traspasa: <nombre>
Huso horario de esta linea de tiempo: UTC

Linea de tiempo
<fecha y hora UTC> - <evento observado, con su fuente>
<fecha y hora UTC> - <evento observado, con su fuente>

Activos e identidades implicados
- <host o IP> (dueno: <equipo o persona>, criticidad: <alta/media/baja>)
- <cuenta> (tipo: <persona/servicio>, privilegiada: <si/no>)

Evidencia de origen
- <fuente>, exportada el <fecha>, guardada en <ruta exacta>

Comprobado
- <qué se ha verificado, con qué metodo>

NO comprobado
- <qué queda pendiente de verificar>

Contencion ya aplicada
- <accion>, <hora UTC>, ejecutada por <quien>

Para reunir la evidencia de origen que este documento referencia, exportar el canal completo (o el subconjunto filtrado que corresponda) a un fichero que quede fuera del ciclo de rotación del propio log es un paso previo casi siempre necesario, con la misma orden que ya se usó en el módulo 14 de este curso:

wevtutil epl Security C:evidenciaINC-2026-0714-security.evtx

Compartir información con criterio: el marco TLP 2.0

Parte de lo que va en un traspaso (nombres de activos internos, identidades reales, detalles de una intrusión en curso) no es información para repartir sin filtro. El Traffic Light Protocol, mantenido por FIRST, resuelve esto con un sistema de cuatro etiquetas que cualquier destinatario reconoce sin tener que leer un párrafo de contexto cada vez. La versión vigente es TLP 2.0, autoritativa desde agosto de 2022 según la propia página de definiciones y guía de uso de FIRST; no hay ninguna versión posterior publicada a fecha de esta sesión de trabajo, así que 2.0 sigue siendo la referencia correcta.

Etiqueta	Color	Hasta dónde se puede compartir
TLP:RED	Rojo	Solo las personas presentes en el intercambio original; no se reenvía a nadie más.
TLP:AMBER+STRICT	Ámbar (variante restringida)	Solo dentro de la propia organización del receptor, sin extenderlo ni siquiera a sus clientes.
TLP:AMBER	Ámbar	Dentro de la organización del receptor y de sus clientes, solo con necesidad real de conocerlo.
TLP:GREEN	Verde	Con la comunidad y las organizaciones socias del receptor, nunca por un canal de acceso público.
TLP:CLEAR	Blanco / transparente	Sin restricción de difusión.

La etiqueta TLP:AMBER+STRICT es la pieza que más gente pasa por alto: no es una cuarta variante independiente de ámbar, es una restricción explícita sobre la etiqueta base. Si la fuente no dice nada más, TLP:AMBER deja compartir tanto dentro de la organización receptora como con sus clientes; solo cuando la fuente añade el sufijo +STRICT esa información queda encerrada dentro de la propia organización, sin salir ni siquiera hacia sus clientes. Un traspaso interno de SOC a equipo de DFIR, dentro de la misma organización, es un caso razonable para TLP:AMBER+STRICT por defecto: contiene detalle operativo (activos, identidades, técnicas de contención en marcha) que no tiene ningún motivo para salir de casa mientras el caso sigue abierto.

La propia especificación de FIRST fija cómo debe marcarse la etiqueta según el canal: en mensajería como el correo, debe ir en el asunto del mensaje y también justo antes del contenido al que aplica. Un ejemplo de cómo queda eso aplicado al traspaso de este módulo:

Asunto: [TLP:AMBER+STRICT] Traspaso de caso INC-2026-0714 a DFIR

En documentos, la misma especificación exige la etiqueta en la cabecera y en el pie de cada página, no solo en la portada, precisamente para que un documento de varias páginas no pierda su clasificación si alguien reenvía solo una de ellas.

Cerrar un falso positivo sin perder lo aprendido

Cerrar un falso positivo como «descartado» y pasar a la siguiente alerta es la forma más rápida de vaciar la cola y la forma más segura de repetir el mismo trabajo la próxima vez que dispare la misma regla. Lo que convierte un cierre en algo útil es registrar, de forma consistente, tres cosas: qué se comprobó exactamente para llegar a la conclusión de que era benigno, si el patrón que lo causó es sistémico (va a volver a disparar mientras exista esa actividad legítima) o fue un caso aislado, y qué acción de ajuste se ha tomado como consecuencia, si es que se ha tomado alguna.

Cuando el patrón es sistémico (una cuenta de aprovisionamiento que crea cuentas locales de forma rutinaria y legítima, por ejemplo, sobre la misma regla de creación de usuario local que se usó de ejemplo en el módulo 14) la respuesta correcta casi nunca es reescribir la condición de la regla original a mano. La especificación de filtros de Sigma, ya vista en el módulo 7, existe exactamente para este caso: un fichero de filtro aparte que referencia la regla afectada por su id y añade la exclusión, sin tocar la regla original ni arriesgarse a que alguien deshaga el ajuste la próxima vez que la regla se actualice desde su fuente. Este es un ejemplo construido para el caso de este módulo, no una regla publicada en ningún repositorio:

title: Filter provisioning account for local user creation
description: |
    Filters local user creation events generated by the approved
    provisioning account svc-provision, confirmed as legitimate
    activity during the triage of INC-2026-0714.
logsource:
    product: windows
    service: security
filter:
    rules:
        - 66b6be3d-55d0-4f47-9855-d69df21740ea
    selection:
        SubjectUserName: 'svc-provision'
    condition: selection

El campo rules apunta al identificador de la regla real «Local User Creation» que ya se citó en el módulo 14 de este curso, así que este filtro no es una regla independiente, es una exclusión que se aplica sobre ella sin reescribirla. Ese ajuste, documentado y trazable hasta el caso que lo motivó, es exactamente la materia prima que alimenta el trabajo de tuning que cubre en profundidad el módulo 15 de este curso, sobre detection-as-code: filtros versionados en git en vez de condiciones parcheadas a mano, con su propia revisión antes de llegar a producción.

Cuando el patrón no es sistémico (un caso aislado, sin motivo para pensar que se va a repetir) no hace falta ningún ajuste de regla, pero el registro del cierre sigue mereciendo la misma constancia: qué se comprobó y por qué se descartó, aunque sea en una línea. Dentro de seis meses, cuando la misma regla vuelva a disparar sobre el mismo activo, ese registro es la diferencia entre investigar desde cero otra vez o recuperar en segundos el contexto que ya se resolvió una vez.

El informe mensual que de verdad se lee

La mayoría de informes mensuales de un SOC fracasan por la misma razón: enumeran actividad (cuántas alertas se procesaron, cuántos tickets se cerraron) sin decir nada sobre si esa actividad protege mejor a la organización que el mes anterior. El libro de referencia del sector sobre esta materia, 11 Strategies of a World-Class Cybersecurity Operations Center, de Kathryn Knerler, Ingrid Parker y Carson Zimmerman (MITRE, segunda edición, 2022), dedica una estrategia completa a esto y propone, entre otras, una métrica que encaja de forma directa con este curso: el porcentaje de técnicas de interés de MITRE ATT&CK para las que el SOC tiene una detección real, no solo catalogada. Esa misma idea, medida con la herramienta correcta, es justo lo que trabajó el módulo 8 de este curso con DeTT&CT.

Seis apartados, combinando esa fuente con lo que ya se ha cubierto en este curso, sostienen un informe mensual que aporta algo más que ruido de actividad:

Apartado	Qué recoge
Cobertura con telemetría comprobada	Cuántas técnicas ATT&CK tienen, de verdad, una fuente de datos que llega al SIEM y una regla que la consulta (no cuántas reglas existen en el repositorio).
Detecciones nuevas	Qué reglas se desplegaron este mes y a qué técnica corresponde cada una.
Detecciones retiradas	Qué reglas se apagaron y el motivo concreto: telemetría perdida, falso positivo estructural sin arreglo razonable, o sustitución por una detección mejor.
Técnicas validadas este mes	Qué técnicas se probaron de verdad con un test atómico o un ejercicio de purple team, según el ciclo del módulo 14, y no solo «existe una regla que dice cubrirla».
Incidentes escalados	Cuántas alertas cruzaron el umbral de este módulo hacia el DFIR, con su severidad y el tiempo transcurrido hasta el traspaso formal.
Puntos ciegos conocidos	Qué no se está viendo todavía, y por qué: un activo sin agente desplegado, una fuente de datos que se cortó y nadie lo ha resuelto, una técnica sin ninguna cobertura.

El último apartado es el que casi nunca aparece, y es el más valioso de los seis. El propio libro de MITRE lo explica con una frase que merece citarse tal cual: los cambios constantes en los sistemas de una organización (instalaciones, migraciones, bajas de equipos) «presentan a menudo puntos ciegos en la cobertura de monitorización», y por eso «los sensores y los orígenes de log necesitan su propia vigilancia rutinaria para asegurar que funcionan como se espera». Un punto ciego no es un fallo vergonzoso que ocultar, es una consecuencia normal de operar un entorno que cambia todo el tiempo, y la única forma de que deje de crecer sin control es escribirlo cada mes, con el mismo detalle que el resto del informe: qué parte de la organización no se está vigilando todavía, desde cuándo, y qué haría falta para cerrar ese hueco. Un informe que solo enseña lo que sí se ve invita a pensar que se ve todo; uno que también enseña lo que no se ve todavía es el único de los dos que un auditor, un nuevo responsable de SOC o el propio equipo de respuesta a incidentes puede usar para algo real.

Cómo seguir después de este curso

Este curso termina en el punto exacto en el que una alerta se convierte en incidente confirmado y cambia de manos. A partir de ahí, contener, preservar evidencia, reconstruir la cadena de ataque completa y coordinar la comunicación con el negocio es terreno del curso de DFIR de este centro, con su propio ciclo PICERL y sus propias herramientas de análisis forense. Buena parte de las detecciones de este curso (movimiento lateral, abuso de credenciales, cuentas privilegiadas) dependen de un directorio bien gobernado detrás; el curso de defensa de Active Directory cubre ese lado, el del bastionado y la identidad, que aquí solo se ha mirado desde el ángulo de qué detectar cuando algo falla. Y si el trabajo del día a día empieza a chocar con preguntas de gobierno (qué política obliga a retener esta evidencia cuánto tiempo, qué marco de cumplimiento exige demostrar esta cobertura), el curso de GRC es donde se resuelven esas preguntas con propiedad, no de memoria.

Para seguir creciendo dentro del propio oficio de operaciones y detección, sin cambiar de especialidad, este centro mantiene un mapa de certificaciones de seguridad con su propio bloque dedicado a defensa, SOC y respuesta, que reseña opciones como las de GIAC orientadas a análisis de intrusión y detección, o certificaciones más asequibles centradas en el perfil de analista de SOC. No se reproducen aquí precios ni fechas de examen porque cambian con frecuencia y esa página se mantiene actualizada; consúltala directamente cuando llegue el momento de decidir por cuál seguir.

Ejercicio: redactar el traspaso formal de una alerta confirmada

Este ejercicio retoma el escenario de creación de cuenta local que ya se validó en el módulo 14 (técnica T1136.001, test «Create a new user in PowerShell» de Atomic Red Team, Event ID 4720, regla Sigma «Local User Creation» de SigmaHQ) y lo convierte en un caso que sí cruza el umbral de escalado, para que el traspaso tenga contenido real que documentar.

1. En tu máquina de laboratorio, repite la ejecución del test de T1136.001 tal como se hizo en el módulo 14. Confirma que el Event ID 4720 aparece y que la regla «Local User Creation» lo habría capturado.
2. Inmediatamente después, inicia sesión de forma interactiva con esa cuenta nueva (por ejemplo con runas /user:<nombre-de-la-cuenta> cmd, o mediante un intento de escritorio remoto si tu laboratorio lo permite) desde el propio equipo o, si tienes una segunda máquina de laboratorio, contra ella. Esto genera una segunda señal (un inicio de sesión de una cuenta local recién creada, sin historial previo) que combinada con la primera es justo el tipo de patrón que un criterio de escalado explícito, como los de este módulo, debería marcar para revisión inmediata.
3. Redacta, por escrito, el criterio exacto de tus propios criterios de escalado que hace que este caso cruce la línea de alerta a incidente. No vale «parecía sospechoso»: tiene que ser el mismo tipo de frase concreta que se ha visto en la sección de criterios de escalado de este módulo.
4. Exporta la evidencia con wevtutil epl Security <ruta>evidencia.evtx y anota la ruta exacta donde queda guardada.
5. Redacta el traspaso formal completo con la plantilla de este módulo: línea de tiempo en UTC, activos e identidades implicados, origen de la evidencia, qué has comprobado y qué no (sé honesto: si no revisaste, por ejemplo, si hubo algún proceso hijo sospechoso lanzado desde esa sesión, anótalo en el apartado de lo no comprobado, no lo omitas), y la contención que ya hayas aplicado (como mínimo, deshabilitar la cuenta creada).
6. Marca el documento completo con la etiqueta TLP que le corresponda si, en un caso real, este traspaso fuera solo para consumo interno de tu propio equipo, y escribe la línea de asunto tal como la marcaría esa etiqueta.
7. Como cierre del ejercicio, escribe también la otra rama posible: imagina que la cuenta hubiera resultado ser de un proceso de aprovisionamiento legítimo. Redacta el cierre de ese falso positivo siguiendo los tres puntos de la sección correspondiente de este módulo, y adapta el filtro Sigma de ejemplo de este módulo a tu propio caso.

Preguntas frecuentes

¿Qué diferencia hay, en la práctica, entre severidad y prioridad?

La severidad la fija quien escribe la regla y no cambia según dónde dispare. La prioridad (o urgencia) sí cambia, porque depende de qué activo o qué identidad está implicada en ese disparo concreto. La misma regla, con la misma severidad, puede merecer una respuesta muy distinta según si toca un servidor de pruebas o un controlador de dominio.

¿Quién decide si una alerta se convierte en incidente?

Nadie lo decide en el momento, si el SOC está bien organizado: lo decide un criterio escrito de antemano, con ejemplos concretos, que cualquier analista puede aplicar sin tener que improvisar. La persona de guardia aplica ese criterio, no inventa uno propio caso por caso.

¿Hace falta usar las etiquetas TLP también dentro del propio SOC, sin salir de la organización?

Sí tiene sentido, sobre todo con TLP:AMBER+STRICT para información operativa sensible que no debe salir ni siquiera hacia los clientes de la organización. Usar TLP de forma consistente desde dentro evita el error de etiquetar algo solo cuando ya va a salir hacia fuera, momento en el que es más fácil olvidarlo.

¿Qué se hace si, al cerrar un falso positivo, aparece indicio de que en realidad hay algo real de otro tipo?

Se reabre como alerta nueva y se aplican los criterios de escalado desde cero, sin arrastrar la conclusión inicial de «falso positivo» a la nueva investigación. El cierre original queda documentado igualmente, porque explica por qué se llegó a esa primera conclusión, aunque resultara incompleta.

¿El huso horario de la línea de tiempo importa tanto como para dedicarle una sección aparte?

Sí, porque distintas herramientas muestran la misma marca de tiempo en huso local o en UTC según su configuración, y mezclar ambos sin declararlo puede reconstruir un orden de eventos que nunca ocurrió así. Fijar UTC como referencia y anotarlo una sola vez al principio del traspaso evita ese error concreto.

¿El informe mensual del SOC hay que enseñárselo a todo el mundo, tal cual?

No necesariamente en la misma versión. El apartado de puntos ciegos conocidos, por ejemplo, es información operativa sensible (describe dónde es más fácil que un ataque pase desapercibido) y puede merecer una etiqueta TLP más restrictiva que un resumen ejecutivo de cobertura pensado para el comité de dirección.