Runtime Detection
Runtime Detection identifies matching activity in collected events. It does not block a process. Use Runtime Blocks when you intend to prevent an operation.
Open Detect > Runtime Detection. Creating or changing rules requires Operator or Admin access.
Choose a view
| View | Use it to |
|---|---|
| Analytics | Review detection activity and the processes, techniques, and sensors involved. |
| Custom Rules | Create, inspect, and edit your organization's detection conditions. |
| Built-in Rules | Review and manage the supplied detection rules. |
| Recent Matches | Open the evidence that matched a rule. |
Existing custom detection policies from the former Guardian screen are managed in Custom Rules. You do not need to recreate them.
Create a custom rule
- Open Custom Rules and select Create detection rule.
- Enter a name and description that explain the behavior you want to find.
- Choose the rule type and enter its matching conditions.
- Set the sensor scope and severity. Add a MITRE ATT&CK technique when relevant.
- Choose the response: no additional action, a webhook notification, an investigation, or both.
- Review the query validation and correct any reported fields or conditions.
- Save the rule and confirm its enabled state.
A query condition describes which recorded events should match. It is not a full SQL statement or an SPL query. Use the fields and examples offered by the editor.
For a sequence rule, review the order of conditions and the time allowed between them. Matching one step does not establish that the entire sequence occurred.
TIP
Start with a narrow sensor scope and a known test activity. An empty match history can mean that the behavior has not occurred or that the required evidence has not been captured.
Inspect and edit
Use Inspect rule to review the saved conditions, scope, severity, and response. Use Edit rule to change them.
After saving:
- Reopen the rule to confirm the intended settings.
- Check that it is enabled when you want it to evaluate new activity.
- Generate a known test condition and review Recent Matches.
- Verify the configured notification or investigation separately.
If the Console reports that another user changed the rule, reload it before applying your changes. This avoids replacing someone else's update.
Disabling a rule stops new evaluations without deleting its existing match history. Delete a rule only when you no longer need its configuration.
Review built-in rules
Open Built-in Rules to search the supplied rules and inspect their purpose and recent activity. Review the rule's enabled state before relying on it.
Use custom rules for organization-specific detection. Do not create a duplicate rule solely because a supplied rule has no recent matches.
Investigate a match
- Open Recent Matches.
- Select a match to open Investigate with its sensor and time context.
- Read the event evidence, process identity, and related activity.
- Open or link an investigation case when further analysis is needed.
A detection is a reason to investigate, not proof that an attack succeeded. Confirm the actual behavior before taking enforcement action.
Notifications and investigations
A webhook response needs a configured destination. A successful destination test verifies connectivity; generate a matching event to verify the rule's actual delivery.
Investigation responses create or link investigation work. They do not terminate a process or isolate a host.
Troubleshooting
| Symptom | What to check |
|---|---|
| Rule cannot be saved | Correct the condition identified by validation; use supported fields and operators. |
| No matches | Check enabled state, sensor scope, observation time, and whether the required activity is captured. |
| Too many matches | Narrow the behavior or target scope and review representative matches before changing severity. |
| No notification | Check the selected response, destination state, and delivery result. |
| A match is no longer available | Confirm the search range and your access; the original event may have passed the retention period. |