Ciberseguridad y seguridad de la información

Reglas y Building Blocks de QRadar: Guía práctica

6 min de lecturaPublicado: 5 de agosto de 2026

Ilustración visual profesional sobre QRadar Rules and Building Blocks en el campo de SIEM y detección

Respuesta rápida

En QRadar, una Regla es un conjunto de Tests que dispara una Respuesta cuando se cumplen las condiciones. Un Building Block utiliza los mismos Tests para describir un grupo o lógica recurrente, pero no dispara una Respuesta por sí mismo. Una buena planificación comienza con el Caso de Uso y los datos, ordena los Tests desde los más baratos y restrictivos hasta los más caros, utiliza el Estado y los conjuntos de referencia con precaución, y se prueba antes de su implementación en producción.

El Custom Rules Engine (CRE) es el motor que examina los eventos, flujos y ofensas frente a las reglas de QRadar. Una buena regla no es una única “sentencia si-entonces”. Es la traducción de un caso de uso lógico a un sistema en tiempo real: qué datos entran, cuáles son las condiciones, cuál es la ventana de tiempo, cómo se mantiene el estado, cuál es la unidad de agrupación y qué sucederá cuando haya una coincidencia.

Los Building Blocks permiten separar el conocimiento ambiental de la lógica de la regla. En lugar de escribir en cada regla una lista de servidores de correo, escáneres de vulnerabilidades o cuentas privilegiadas, se puede definir un Building Block y usarlo en varias reglas. Dado que un Building Block no tiene respuestas, sirve como un componente lógico que se puede mantener.

Cómo el CRE evalúa Eventos y Flujos

Cuando un Evento o Flujo llega a QRadar, se normaliza y pasa a través del CRE. El motor examina las Reglas relevantes según el tipo de dato. Un Test puede verificar una Propiedad simple, una categoría, un Log Source, una ubicación de red, un valor en una lista, una Regex en el Payload o una secuencia a lo largo del tiempo. Si se cumplen todas las condiciones, se activa una Rule Response.

El orden de los Tests es importante para el rendimiento. IBM recomienda comenzar con condiciones que reducen la cantidad de datos: Tipo de Log Source, Red, Categoría de Evento o Dirección. Luego se añaden IP, Puerto, Nombre de usuario u otras propiedades. Payload y Regular Expression deben ir al final, ya que son más costosos. Una Regla que aplica una Regex a todos los Eventos de la organización puede generar una sobrecarga incluso si el resultado es correcto.

Regla versus Building Block

Característica	Regla	Building Block
Propósito	Identificar una situación y disparar una Respuesta	Describir un grupo o lógica recurrente
Tests	Sí	Sí, los mismos tipos de Tests
Respuesta	Sí, según la definición	No
Reutilización	Posible, pero menos modular	Diseñado para ser utilizado dentro de Reglas y otros Building Blocks
Ejemplo	Múltiples fallos para diferentes cuentas desde la misma IP	BB: Cuentas Privilegiadas o BB: Escáneres Aprobados

Un Building Block no es una “Regla débil”. Es una librería de lógica. Por ejemplo, BB:Approved Scanners puede contener IPs o rangos de red de escáneres de vulnerabilidades. Una Regla para identificar un escaneo externo puede añadir la condición NOT when source matches BB:Approved Scanners. Si el escáner cambia, se actualiza un solo componente.

Sin embargo, el uso excesivo de Building Blocks crea una cadena de dependencias difícil de entender. Documente el Owner, Propósito y Consumidores. Un nombre como BB:Temp2 no es útil. Un buen nombre explica el Alcance, por ejemplo BB:HostDefinition:DomainControllers o BB:UserDefinition:PrivilegedAccounts.

Tipos de Reglas

QRadar soporta diferentes tipos de Reglas. Las reglas de Evento examinan los datos de Log Activity. Las reglas de Flujo examinan Network Activity. Las reglas Comunes pueden trabajar con propiedades compartidas entre Eventos y Flujos. Las reglas de Ofensa examinan las propiedades de las Ofensas para activar Respuestas adicionales. La elección debe coincidir con el dato y la limitación.

Si la pregunta es “¿Un usuario falló al iniciar sesión muchas veces?”, una regla de Evento es adecuada. Si la pregunta es “¿Un Host generó tráfico de un volumen inusual?”, una regla de Flujo puede ser adecuada. Si es necesario responder solo cuando una Ofensa específica superó una Magnitud o recibió una propiedad, una regla de Ofensa puede ser relevante.

Tests con Estado y Umbrales

Un Test con Estado recuerda la actividad a lo largo de una ventana de tiempo. Ejemplos: más de N Eventos de la misma Fuente, actividad hacia más de M Destinos, o una secuencia de eventos. Es necesario definir una Clave sobre la cual se cuenta: IP de origen, Nombre de usuario, Destino, combinación de campos u otro valor. Una Clave incorrecta mezclará entidades o dividirá un Patrón.

El Umbral debe basarse en una Línea de Base. Diez fallos en cinco minutos pueden ser inusuales para un usuario normal, pero esperados en un servidor RADIUS. Una ventana corta detecta ráfagas; una ventana larga detecta actividad lenta pero aumenta el Estado y el ruido. Escriba de antemano cuál es el comportamiento de la amenaza, no solo un “número que parece razonable”.

Componente	Pregunta de diseño	Riesgo si es incorrecto
Clave de agrupación	¿Sobre qué entidad se cuenta?	Mezcla de usuarios o división del atacante
Umbral	¿Qué volumen justifica la detección?	Ruido o omisión
Ventana de tiempo	¿Cuál es el ritmo del comportamiento?	Pérdida de un ataque lento o Estado innecesario
Reiniciar/Caducidad	¿Cuándo expira el historial?	Eventos antiguos afectan una nueva decisión
Exclusiones	¿Qué actividades son esperadas?	Punto ciego generalizado

Respuestas y Conjuntos de Referencia

Una Respuesta puede crear una Ofensa, enviar un Email o Syslog, añadir un valor a un Reference set, realizar un Dispatch de una Acción u otra operación según los permisos y la versión. Separe la Detección de la Respuesta: una Regla puede ser correcta pero una Respuesta peligrosa. Al principio del Ajuste, prefiera la creación de una Ofensa o Notificación antes del bloqueo automático.

Un Reference set es una colección de valores únicos que se puede utilizar en búsquedas, Filtros, Tests y Respuestas. Se pueden guardar IOCs, usuarios, IPs o Contexto de Negocio. Una Regla puede verificar si un valor está en la lista o añadirlo. Defina Tipo, TTL o proceso de limpieza, Owner y origen. Un Reference set antiguo de IOCs puede generar Falsos Positivos u ocultar actividad si se utiliza para Whitelist.

Ejercicio: Diseño de una Regla de múltiples etapas para Password Spray

El ejercicio es solo un diseño en un entorno de laboratorio. El objetivo: identificar una IP de origen que genera fallos contra muchos usuarios, y no solo muchos fallos contra un solo usuario.

Etapa	Lógica propuesta	Explicación
Alcance	Eventos de la categoría Fallo de Autenticación de fuentes idénticas	Filtro temprano
Red	La fuente no está en BB:ApprovedIdentityInfrastructure	Excluye infraestructura aprobada de forma modular
Estado	La misma IP de origen frente a al menos 8 nombres de usuario diferentes en 10 minutos	Expresa Spray y no Brute force para una sola cuenta
Contexto	Destino en el ámbito organizacional y el usuario no es una cuenta de prueba	Añade alcance empresarial
Respuesta	Crear Ofensa + Añadir Fuente a un conjunto de referencia temporal	Permite un caso y seguimiento limitado en el tiempo

Antes de la implementación, verifique los datos de VPN, Proxy y NAT. Una dirección de origen compartida puede representar a muchos usuarios legítimos. Podría ser necesaria una Clave combinada de Origen, Aplicación y Tenant. También verifique si el Nombre de usuario está normalizado; un cambio de letras o un prefijo de Dominio puede inflar el número de usuarios únicos.

Pruebas y Ajuste

Escriba la especificación de detección: Comportamiento de la amenaza, Fuente de datos, campos, clave, umbral, ventana, excepciones y respuesta.
Realice una búsqueda histórica para entender la Línea de Base. El CRE opera en tiempo real, pero una búsqueda histórica ayuda a evaluar el volumen y los ejemplos.
Pruebe casos positivos simulados y casos negativos. Asegúrese de que la Regla no dependa de un campo que falta en algunas Fuentes de Registro.
Implemente en un entorno de prueba o en modo de respuesta conservador. Mida el volumen de ofensas y la contribución de eventos.
Verifique el rendimiento: Tests amplios al principio, Regex/Payload al final, y evite una regla global si una local es suficiente.
Documente cada Excepción con un motivo, un Propietario y una fecha de vencimiento. Prefiera un Building Block o un Reference set administrado.
Después de un cambio, realice una prueba de regresión en casos reales y simulados.

Lista de verificación antes de Habilitar

El Caso de Uso y la amenaza están formulados en un lenguaje claro.
El tipo de Regla es adecuado para Evento, Flujo u Ofensa.
Los Tests están organizados desde los más restrictivos y económicos hasta los más costosos.
La Clave de agrupación, el Umbral y la Ventana de tiempo han sido verificados.
Los Building Blocks están documentados y no crean dependencias circulares.
Los Reference sets incluyen Owner, origen y proceso de caducidad.
La Respuesta es segura y apropiada para el nivel de Confianza.
Existe un Plan de Ajuste, Métricas y Reversión.

Errores comunes

Comenzar con Regex en el Payload en lugar de filtrar Log Source y categoría.
Copiar una Regla de otro entorno sin jerarquía de red y contexto de activos.
Usar un Building Block como una Whitelist generalizada.
Definir una regla Global cuando una Local es suficiente.
Contar por IP de origen en un entorno con NAT sin contexto adicional.
Añadir valores a un Reference set sin Expiration.
Activar una respuesta automática antes del Ajuste.

Resumen y CTA

Construya en el laboratorio una especificación de Regla para Password Spray, pero no la implemente de inmediato. Presente los Tests en orden, marque cuáles son sin estado y cuáles con estado, defina un Building Block para la infraestructura aprobada y escriba una Respuesta conservadora. Luego, pida a otra persona que explique la regla solo a partir de la documentación. Si no lo logra, la regla aún no está lista.

Preguntas frecuentes

¿Puede un Building Block crear una Ofensa?

No directamente. Utiliza Tests pero no incluye Respuestas. Una Regla que lo refiera puede crear una Ofensa.

¿Cuál es la diferencia entre una regla Local y una Global?

Una Local se procesa en el Event Processor donde se recibieron los datos. Una Global envía las coincidencias a la consola para un procesamiento más amplio y puede consumir más recursos. La elección depende del Alcance.

¿Cuándo usar un Reference set?

Cuando se necesita una lista de valores administrada para usar en búsquedas, Tests o Respuestas, por ejemplo, IOCs o un grupo de usuarios. Se debe gestionar la caducidad y el origen.

¿Cómo se elige el Umbral?

Mediante un modelo de amenaza y una Línea de Base local. No hay un número universal. Verifique también la Distribución y no solo el promedio.

¿Puede una Regla verificar una secuencia?

Sí, ciertos tipos de Tests rastrean series y Contadores a lo largo del tiempo. Es necesario definir una Clave y una ventana y verificar los costos del Estado.