Redacción de reglas de detección y correlación
Cree consultas SPL de Splunk o KQL de Kibana para detectar fuerza bruta, movimiento lateral y exfiltración de datos.
Redacción de reglas de detección y correlación es una lección gratuita de Cyber Security Academy en CoddyKit. Esta es la lección 3 de 4. Puedes leer la lección completa abajo gratuitamente — luego la practicas en el navegador con un editor de código integrado y un tutor de IA 24/7. Forma parte de la ruta de aprendizaje de Cyber Security Academy, y tu progreso se sincroniza en la web y la app de CoddyKit. El curso de Cyber Security Academy incluye 4 lecciones en total.
Fundamentos de la ingeniería de detección
Las reglas de detección convierten los comportamientos de los atacantes en lógica de consulta que se activa cuando el patrón aparece en los registros. Una buena ingeniería de detección debe ser lo bastante específica para evitar falsos positivos, pero lo bastante amplia para detectar las distintas variantes de un ataque.
SPL de Splunk: lenguaje de procesamiento de búsquedas
Las consultas SPL utilizan una sintaxis basada en tuberías: búsqueda → transformación → visualización. Comience con un índice y un sourcetype, filtre los eventos relevantes y agregue los resultados o genere alertas a partir de ellos.
# Basic SPL structure
index=security sourcetype=WinEventLog EventCode=4625
| stats count by src_ip, user
| where count > 10
| sort -count
# Explanation:
# Search Security index for logon failures
# Count failures per source IP + user
# Alert if more than 10 failures
# Sort descending by countDetección de fuerza bruta en Splunk
Detección de fuerza bruta: cuente los inicios de sesión fallidos por origen y genere una alerta cuando se supere el umbral dentro de un intervalo de tiempo. Correlacione un inicio de sesión correcto posterior a los fallidos para detectar ataques de credential stuffing.
# Failed logins by source IP
index=security EventCode=4625
| bucket _time span=5m
| stats count as failures by _time, src_ip
| where failures > 20
| table _time, src_ip, failures
# Success after failures (account takeover)
index=security EventCode=4625 OR EventCode=4624
| stats values(EventCode) as events by src_ip
| where mvfind(events,"4625") >= 0 AND mvfind(events,"4624") >= 0KQL de Kibana para la detección
Kibana Query Language (KQL) filtra eventos para su investigación. Es más legible que Lucene para los analistas; úselo en búsquedas guardadas y reglas de alerta dentro de Kibana.
# KQL examples:
# Failed SSH logins
event.action: "ssh_login_failed" and source.ip: *
# Nmap scan detection
not destination.port: (80 or 443 or 22) and event.type: "connection"
# Privilege escalation
process.name: "sudo" and process.args: "-s"Reglas de detección de Elasticsearch
La aplicación Security de Kibana incluye un motor de reglas de detección. Las reglas pueden basarse en umbrales (recuento de eventos), en consultas (un patrón de evento específico), en anomalías de ML o en secuencias EQL (Event Query Language).
# EQL sequence rule example (Kibana Security):
sequence by host.name
[process where process.name == "cmd.exe"]
[network where destination.port == 4444]
# Detects: cmd.exe followed by connection to port 4444
# (common reverse shell pattern)Detección del movimiento lateral
Detecte el movimiento lateral mediante: creación de servicios con PsExec (evento 7045), ejecución remota mediante WMI, acceso inusual a recursos compartidos administrativos (evento 5140) y creación remota de nuevas tareas programadas.
# Splunk: detect PsExec-style lateral movement
index=security EventCode=7045
| where Service_Name="PSEXESVC" OR Service_File_Name="\\*\\*.exe"
| table _time, ComputerName, Service_Name, Service_File_Name
# WMI remote execution
index=sysmon EventCode=1 ParentImage="*WmiPrvSE.exe"
| table _time, host, CommandLine, UserDetección de la exfiltración de datos
Detecte la exfiltración mediante: transferencias salientes de gran volumen a destinos inusuales, consultas DNS con subdominios anormalmente largos (túnel) y beaconing HTTPS a intervalos regulares.
# DNS tunneling detection in Splunk
index=dns
| eval subdomain_len=len(subdomain)
| where subdomain_len > 50
| stats count by query, src_ip
| sort -count
# Large outbound (NetFlow/firewall logs)
index=firewall action=allow direction=outbound
| stats sum(bytes) as total_bytes by dest_ip, src_ip
| where total_bytes > 100000000 # 100MB thresholdThreat hunting con búsquedas guardadas
Guarde las consultas de detección que utilice con frecuencia como búsquedas programadas que envíen un correo electrónico o creen incidentes. Establezca intervalos de tiempo y umbrales adecuados para equilibrar la rapidez de detección con la tasa de falsos positivos.
Detección asignada a MITRE ATT&CK
Asigne las reglas de detección a las técnicas de ATT&CK. Esto muestra las brechas de cobertura y ayuda a priorizar nuevas reglas. Herramientas como ATT&CK Navigator permiten visualizar qué técnicas detecta y ante cuáles carece de visibilidad.
Ajuste para reducir los falsos positivos
Las reglas nuevas suelen activarse de forma demasiado amplia. Ajústelas añadiendo exclusiones para fuentes conocidas como legítimas, elevando los umbrales, incorporando campos contextuales (horario laboral, IP de análisis conocidas) y validándolas con datos históricos antes de activarlas.
Fatiga por alertas
Demasiadas alertas de baja calidad hacen que los analistas las ignoren, lo que frustra el propósito del sistema. Priorice la calidad sobre la cantidad: 10 alertas de alta fidelidad al día son mejores que 500 alertas ruidosas. Suprima, ajuste y retire las reglas de bajo rendimiento.
Comprobación rápida
¿Qué detecta una regla de secuencia EQL que no puede detectar una regla de consulta simple?
Resumen: reglas de detección
La ingeniería de detección convierte las TTP de los atacantes en lógica de consulta. Utilice SPL para Splunk, y KQL y EQL para Kibana Security. Asigne las reglas a MITRE ATT&CK para realizar un seguimiento de la cobertura. Priorice las reglas específicas y de alta fidelidad frente a las reglas amplias y ruidosas. Ajuste continuamente la detección: el panorama de amenazas cambia y su lógica de detección también debe hacerlo.
Preguntas frecuentes
¿La lección «Redacción de reglas de detección y correlación» es gratis?
Sí — el texto completo de «Redacción de reglas de detección y correlación» es gratis para leer aquí en la web. Para practicarla de forma interactiva (editor de código integrado y tutor de IA 24/7) y desbloquear el resto del curso de Cyber Security Academy, actualiza a CoddyKit PRO. El curso de Cyber Security Academy incluye 4 lecciones en total.
¿Qué aprenderé en «Redacción de reglas de detección y correlación»?
Cree consultas SPL de Splunk o KQL de Kibana para detectar fuerza bruta, movimiento lateral y exfiltración de datos. Practicas Cyber Security Academy con código real que ejecutas directamente en el navegador, y un tutor de IA 24/7 responde tus preguntas mientras trabajas en la lección.
¿Necesito experiencia previa para empezar Cyber Security Academy?
No se requiere experiencia previa. Cyber Security Academy en CoddyKit está estructurado para principiantes hasta estudiantes avanzados, así que puedes empezar aquí o desde el inicio y avanzar a tu ritmo. Esta es la lección 3 de 4.
¿Cuánto tiempo toma la lección «Redacción de reglas de detección y correlación»?
La mayoría de las lecciones de CoddyKit toman alrededor de 5–10 minutos. Cada una es compacta e interactiva, así que avanzas constantemente y retomas exactamente por donde dejaste en la web y la app.
¿Puedo escribir y ejecutar código en esta lección de Cyber Security Academy?
Sí. Cada lección de Cyber Security Academy incluye un editor de código integrado, así que escribes y ejecutas código real directamente en tu navegador y obtienes retroalimentación instantánea de IA — sin configuración local necesaria.
Todas las lecciones de este curso
- Fuentes de registros: del sistema operativo, de red y de aplicaciones
- Arquitectura SIEM e ingesta de registros
- Redacción de reglas de detección y correlación
- Triaje de alertas y flujo de trabajo del SOC