Skip to content
Contact us
  • There are no suggestions because the search field is empty.

Threat Monitoring Rules

Overview

Threat Monitoring’s AI Analyst triages events at the point of detection and automatically closes anything it determines is a non-risk. Rules apply after the AI Analyst has run: they allow you to define scenarios (e.g. threats listing an ex-employees email address) in which threats should be dismissed. 

Use rules anytime you can describe noise with a consistent pattern. 

Use cases

Below are some common scenarios when rules are helpful. 

Use case

Description

Known benign infrastructure

A code repository, forum, or hosted service that triggers matches but isn't yours. Rules filter out signals tied to the irrelevant source.

Former-employee exposure

Stealer log events tied to employees who have left your organization. Once credentials are invalidated, a rule can dismiss future matches. 

Irrelevant data sources

Forums, dumps, or other sources that consistently generate signals unrelated to your risk profile. A rule removes the noise without turning off monitoring of the source type overall.

Confirmed non-impacting patterns

Anything you've previously investigated and determined is not a threat to your organization — a specific repository, URL, or event text you've already decided does not warrant investigation.

Create a rule

Rules are created from the context of an existing threat event. When you start creating a rule, the signal source (for example, code repository, stealer logs, forums) is detected automatically and the available metadata fields update to match.

  1. Click Breach Risk from UpGuard’s left navigation panel. 
  2. Select Threat Monitoring. 
  3. Click a threat to open it. 
  4. Click Manage Threat. 
  5. Click + Configure rule. 
  6. You’ll see the threat’s source auto-populated for you in the Source field. 
  7. Click the Source metadata dropdown and select the information you want to create a rule around. 
  8. Update the Condition and Value fields. Options available in these fields vary based on the field's source. Data from the current threat is used to pre-populate the value field, but you can shorten it (for example, use a domain instead of a full email address) or broaden it to match a partial string.
  9. (optional) Edit the rule name. A name is generated automatically from the conditions you set.
  10. Click Run test. Testing is required before a rule can be enabled. The test runs the rule against all open events from the same source and shows how many currently match.
  11. Review the match count. For example, the test might report that it scanned 4,861 code repository events and matched 20.
  12. If the match count isn't what you expected, adjust the rule's metadata field, condition, or value and run the test again.
  13. Click Confirm and enable when you are happy with the rule. 

Once enabled:

  • All matching open events are immediately closed and marked Closed by Rule. The threats severity remains visible. 
  • Any new signal from the same source that matches the rule's conditions is dismissed automatically.
  • Click into a closed threat to see why the rule was closed. 

🎵 You can create multiple rules for the same source-type or from the same threat. An incoming signal that matches any active rule for its source is dismissed.

Manage rules

All active and inactive rules are listed in Settings. Check settings to see what’s running, pause rules, or review their logic.

  1. Click the Settings (gear) icon in UpGuard's upper right-hand corner.
  2. Click Threat Monitoring Rules. You can see all active, inactive, and archived rules from this page. 
    1. Activate or inactivate a rule: using the “enabled” toggle next to the corresponding rule. The rule will no longer evaluate new threats, but threats the rule previously closed, remain closed. 
    2. Archive a rule: click the archive icon on a rules row. The rule will no longer evaluate new threats, but threats the rule previously closed, remain closed. 
    3. See a rule’s settings: click a rule. 

🧠 You cannot edit a rule’s settings once it’s been created. To achieve that result, archive and recreate the rule with the appropriate configurations. 

Best practices

  • Start narrow. Create rules with specific, stable identifiers — full domains, exact repository names, complete email patterns — and only broaden them once you've confirmed the match set is correct.
  • Always review the test output before enabling a rule. Short keywords and partial matches can unexpectedly catch legitimate threats.
  • Periodically revisit your rules. Noise patterns change as your organization changes — a rule that was correct six months ago might now be dismissing events you care about.