Rule copilot
Describe the behaviour to catch in one sentence and get a QRadar Rule Wizard design: test conditions, rule response, backtest AQL, MITRE ATT&CK, checked against live rules for duplicates. Analysts configure the rule in the wizard; the product never writes to QRadar. Paid capability.
Paid capability, Standard tier (including the 14-day trial) and up.
QRadar 7.5's REST API cannot create custom rules, so this page produces a rule design for a person, not an object to POST: the test conditions to add in the Rule Wizard in order, how to set the rule response, and one AQL that validates the logic on historical data. The product never creates or enables a rule.
Describing the intent
Two inputs:
- Detection intent: spell out the trigger, time window and exclusions, e.g. "same source IP fails authentication against different accounts at least 5 times in 5 minutes, excluding vulnerability scanners". The model's context includes Ariel column names, the log-source catalogue, live rule names (for duplicate marking) and the Building Block list (to reference existing
BB:definitions rather than rewrite them). - Rule type: auto / event / flow / common / offense, the four Rule Wizard types. "Auto" lets the model pick: event fields → event, traffic direction and bytes → flow, both → common, properties of an existing offense → offense.
"Turn into a rule design" on an offense investigation report pre-fills the intent from the verdict.
The generated design
| Section | Content |
|---|---|
| Confidence | The model's own rating of how well the design captures the intent |
| Tags | Rule type, MITRE ATT&CK technique IDs and tactics |
| Rule Wizard tests | Test statements in the order to add them, in the wizard's own wording ("when the event(s) were detected by one or more of these log sources"), parameters filled in |
| Building Blocks used | Which live BB: definitions to select in the wizard |
| Rule response | Actions (create offense / annotate / dispatch), the offense index field (which decides whether one attack merges into one offense), offense name, annotation, reference-set write, and the severity / credibility / relevance dials |
| Backtest AQL | One SELECT … FROM events statement showing what the logic would have matched historically |
| Likely false positives | Which legitimate behaviour would trigger it |
| Tuning | Which BB or reference-set whitelist to add, how to adjust thresholds |
| Similar live rules | Matched against live rule names; duplicates are flagged |
"Run the backtest in Ask AI" carries the backtest AQL into Ask AI to see the last 7 days' hits and obvious false positives before touching the wizard. "Show full design JSON" gives the structured original for copying.
A vague intent gets a refusal that names what is missing (trigger, window or exclusions).
Configuring it in QRadar
Click "Run the backtest in Ask AI" first and look at the last 7 days' hits and false positives.
QRadar → Offenses → Rules → Actions → New Event Rule (or the matching type); add the tests from the "Rule Wizard tests" section one by one with the given parameters.
Set the response from the "Rule response" section. The wrong offense index field splits one attack into many offenses or merges unrelated ones.
Enable as a Rule for a week and watch; if false positives pile up, add the BB or reference-set whitelist from "Tuning".
The backtest AQL only shows what these conditions match on historical events; it cannot reproduce the Rule Wizard's counting windows or function tests. Run Test in the wizard before going live.
Rule library
"Save rule" stores the design in the team library, visible to everyone, to load back, copy again or delete. The library lives in copilot.db.
Triage
A batch of offenses clustered by rule and source; the model rates each cluster's severity, calls false positives, recommends action, and queues them by priority. Paid capability.
Security posture
The first screen after login: offenses in the window, high-severity count, log sources at risk, platform issues, and the top-10 noisiest rules and newest offenses.