Auto-Grouping Configuration

Auto-grouping automatically correlates related alerts into cases, reducing alert fatigue and providing better context for investigations.

How Auto-Grouping Works

When a detection rule fires and creates an alert:

1. Entity Extraction: nano extracts entities (users, hosts, IPs, domains, hashes) from the matched events
2. Rule Matching: The system evaluates enabled grouping rules in priority order
3. Key Computation: A grouping key is computed based on the rule type
4. Case Lookup: If an open case exists with the same grouping key within the time window, the alert is added to it
5. Case Creation: If no matching case exists, a new case is created

┌─────────────┐     ┌─────────────────┐     ┌───────────────────┐
│   Alert     │────▶│ Extract Entities │────▶│ Evaluate Grouping │
│   Created   │     │ (users, hosts,   │     │ Rules (by priority)│
└─────────────┘     │  IPs, etc.)      │     └───────────────────┘
                    └─────────────────┘              │
                                                     ▼
                    ┌─────────────────┐     ┌───────────────────┐
                    │ Create New Case │◀────│ Compute Grouping  │
                    │ (if no match)   │     │ Key               │
                    └─────────────────┘     └───────────────────┘
                            │                        │
                            │                        ▼
                            │               ┌───────────────────┐
                            │               │ Find Open Case    │
                            │               │ with Same Key     │
                            │               └───────────────────┘
                            │                        │
                            │                        ▼ (if found within time window)
                            │               ┌───────────────────┐
                            └──────────────▶│ Add Alert to      │
                                            │ Existing Case     │
                                            └───────────────────┘

Grouping Rules

Rule Configuration

Access grouping rules at Settings > Case Management:

Match Types

Default Rules

nano ships with these default grouping rules:

Configuration Examples

Group by Host (Recommended)

Groups all alerts targeting the same host within a time window:

{
  "name": "Group by Host",
  "match_type": "host",
  "time_window_minutes": 60,
  "priority": 100,
  "title_template": "Multiple alerts on {{host}}",
  "severity_rule": "highest",
  "enabled": true
}

Result: If you get 5 alerts about SRV-PROD-01 within an hour, they all go into one case.

Group by User

Groups alerts involving the same user account:

{
  "name": "Group by User Account",
  "match_type": "user",
  "time_window_minutes": 120,
  "priority": 90,
  "title_template": "Suspicious activity by {{user}}",
  "severity_rule": "highest",
  "enabled": true
}

Result: All alerts for admin@corp.com within 2 hours are grouped together.

Group by Source IP

Groups alerts from the same source IP:

{
  "name": "Group by Source IP",
  "match_type": "ip",
  "time_window_minutes": 30,
  "priority": 80,
  "title_template": "Activity from {{src_ip}}",
  "severity_rule": "highest",
  "enabled": true
}

Result: Scanning or attack activity from 203.0.113.42 is consolidated.

Group by Detection Rule

Groups alerts from the same detection rule:

{
  "name": "Group by Rule",
  "match_type": "rule",
  "time_window_minutes": 120,
  "priority": 70,
  "title_template": "{{rule_name}}",
  "severity_rule": "highest",
  "enabled": true
}

Result: Multiple firings of "Brute Force Attempt" are grouped together.

Severity Rules

When multiple alerts are grouped, the case severity is determined by:

Recommendation: Use highest to ensure critical alerts aren't buried.

Time Windows

The time window determines how long after the last activity a case remains "open" for new alerts:

Time Window Guidelines

Window Behavior

Time Window: 60 minutes

Alert 1 @ 10:00 → Creates Case-1234
Alert 2 @ 10:15 → Added to Case-1234 (within window)
Alert 3 @ 10:45 → Added to Case-1234 (within window)
Alert 4 @ 12:00 → Creates Case-1235 (outside window from Alert 3)

Priority Order

Rules are evaluated in priority order (higher number = higher priority):

Priority 100: Group by Host   ← Evaluated first (default)
Priority 90:  Group by User
Priority 80:  Group by IP
Priority 70:  Group by Rule   ← Evaluated last (default)

How Priority Works

Finding existing cases: Rules are tried in priority order. The first rule that finds a matching open case wins.

Creating new cases: The highest-priority rule that can produce a grouping key is used. This means:

Why "Group by Rule" May Not Work

If you have both "Group by Host" and "Group by Rule" enabled:

Alert 1: Rule X on WS-001 → Creates case keyed by "host:WS-001"
Alert 2: Rule X on WS-002 → Host lookup fails (different host)
                          → Rule lookup fails (case keyed by host, not rule)
                          → Creates NEW case keyed by "host:WS-002"

Result: Alerts from the same rule on different hosts create separate cases, because Host has higher priority.

To Enable Rule-Based Grouping

If you want all alerts from the same detection rule grouped together regardless of host/user:

1. Option A: Disable Host, User, and IP grouping rules — keep only "Group by Rule"
2. Option B: Give "Group by Rule" the highest priority (e.g., priority 200)

API Reference

List Grouping Rules

GET /api/settings/case-grouping

Create Grouping Rule

POST /api/settings/case-grouping
{
  "name": "Group by Host",
  "match_type": "host",
  "time_window_minutes": 60,
  "priority": 1,
  "title_template": "Activity on {{host}}",
  "severity_rule": "highest",
  "max_alerts": 100,
  "enabled": true
}

Update Grouping Rule

PUT /api/settings/case-grouping/:id
{
  "time_window_minutes": 120,
  "enabled": false
}

Delete Grouping Rule

DELETE /api/settings/case-grouping/:id

Best Practices

1. Start with Defaults

The default rules provide good coverage for most environments. Tune based on your specific needs.

2. Use Appropriate Time Windows

• Too short: Cases fragment, losing correlation
• Too long: Unrelated alerts get grouped together

3. Consider Max Alerts

Set max_alerts to prevent cases from becoming unwieldy:

• Default: 100 alerts per case
• High-volume environments: Consider 50 alerts
• Very large cases become difficult to investigate

4. Monitor Rule Effectiveness

Use the audit events to analyze grouping effectiveness:

source_type=case_audit action=created
| stats count by grouping_type
| sort -count

5. Disable Conflicting Rules

If multiple rules match the same alerts, only the highest priority rule is used. Disable lower-priority rules that never match.

Troubleshooting

Alerts Not Grouping

1. Check rule is enabled: Ensure the rule is toggled on
2. Verify time window: The window starts from the last alert, not case creation
3. Check entity extraction: Entities must be present in the matched events
4. Review priority order: Higher-priority rules may be matching first

"Group by Rule" Not Working

If you enabled "Group by Detection Rule" but alerts from the same rule are creating separate cases:

1. Check other enabled rules: Host/User/IP rules have higher default priority
2. Disable higher-priority rules: Turn off Host, User, and IP grouping if you want rule-based grouping
3. Or increase Rule priority: Set "Group by Rule" to priority 200+ to make it highest

Why this happens: When creating a new case, the system uses the highest-priority rule that can extract an entity. Since most alerts have a host or user, those rules always "win" over the Rule grouping type.

Host Grouping Creating Separate Cases

If alerts from the same source machine are creating separate cases:

1. Check if src_host is populated: Run a search to verify:

   your_detection_query | table src_host, dest_host, src_ip, user

2. If only dest_host exists: The system falls back to destination hostname, which varies per connection. Solutions:
   • Lower Host priority below User/IP (e.g., set to 85)
   • Disable Host grouping entirely
   • Configure your log source to populate src_host
3. Use IP grouping instead: If src_ip is consistent, IP grouping (priority 80) may work better

Too Many Cases Created

1. Increase time window: Allow more time for alerts to correlate
2. Check field availability: Verify the UDM fields needed for your grouping type are populated
3. Try a different grouping type: If Host isn't working, try User or IP

Cases Too Large

1. Reduce time window: Limit grouping duration
2. Lower max_alerts: Force new cases after threshold
3. Add more specific rules: Create rules for high-volume detections