Rules and Building Block Design
Rules and Building Block Design tests whether you can decompose detection logic into reusable tests and responses without breaking correlation. QRadar separates what a rule tests from what it does; building blocks are the reusable test layer.
Rule anatomy
A QRadar rule has a type (event, flow, common, or offense), details (name, enabled state, owner, groups), test conditions, and responses. Test conditions evaluate event or flow properties and can combine AND, OR, and NOT. Responses may create an offense, dispatch or log an event, add to a reference set, execute a custom action, or notify. Building blocks contain only tests; they have no responses and must be referenced by a rule or another building block.
Design rules
- Put repeatable whitelists, asset groups, and IOC tests in building blocks.
- Name building blocks with a clear prefix, e.g., BB_Auth_Exceptions, and document intent.
- Keep each block narrow; avoid deep nesting that hides logic.
- Change a building block once and every referencing rule inherits it.
- Test in the rule wizard before enabling; use rule groups for ownership.
- Do not disable a whole rule to handle one exception; add a NOT condition or exception block.
Worked example: Authorized vulnerability scanners in 10.2.0.0/24 trigger scan offenses. Create BB_Authorized_Scanner with tests sourceip in 10.2.0.0/24 AND category is scan. In the scan rule, add a test NOT BB_Authorized_Scanner. Reasoning: the exception is centralized and reusable; a future scanner subnet is added once; the rule still fires for all other sources.
Traps
- Putting responses in a building block.
- Hardcoding the same IP list in several rules.
- Using OR where AND is needed, broadening the rule.
- Disabling a rule instead of adding a tested exception.
- Editing a shared block without checking its rule dependencies.