Skip to main content

SigmaHQ Integration

SigmaHQ is the official repository of Sigma detection rules maintained by the security community. CHAD can sync with SigmaHQ to browse and import thousands of community rules.

What is SigmaHQ?

SigmaHQ contains:
  • Core rules - Production-ready detections for common threats
  • Threat hunting rules - Proactive hunting queries
  • Emerging threat rules - Rapid response to new campaigns
Rules cover:
  • Windows, Linux, macOS
  • Network traffic
  • Cloud platforms (AWS, Azure, GCP)
  • Applications (web servers, databases)

Syncing SigmaHQ

Initial Sync

  1. Navigate to SigmaHQ in the sidebar
  2. Click Sync Repository
  3. Wait for the sync to complete (may take a few minutes)
CHAD clones the repository and indexes all rules.

Automatic Updates

SigmaHQ is updated regularly. Configure automatic sync:
  1. Go to Settings > SigmaHQ
  2. Enable Auto Sync
  3. Set sync frequency (daily recommended)
Auto sync runs in the background and doesn’t interrupt your work.

Browsing Rules

After syncing, browse the rule library: Search by:
  • Title - Rule name
  • Tags - MITRE ATT&CK techniques
  • Product - Windows, Linux, network
  • Severity - Risk level

Filters

Filter rules by:
FilterOptions
CategoryCore, Threat Hunting, Emerging Threats
Productwindows, linux, macos, network, cloud
Severitycritical, high, medium, low, informational
Statusstable, test, experimental

Rule Preview

Click any rule to preview:
  • Full Sigma YAML
  • Rule metadata (author, references)
  • MITRE ATT&CK mappings
  • False positive notes

Importing Rules

Single Rule Import

  1. Find the rule you want
  2. Click Import
  3. Rule is copied to your local rules
  4. Edit if needed, then deploy

Bulk Import

Import multiple rules at once:
  1. Use filters to find relevant rules
  2. Select rules with checkboxes (or “Select All”)
  3. Click Bulk Import
  4. Review the import summary
  5. Confirm import
Start with stable, high-severity rules for your primary log sources (e.g., Windows Security logs).

Import Considerations

Field Mapping

SigmaHQ rules use standard Sigma field names. You need:
  1. Field mappings configured for your log schema
  2. Index patterns that match the rule’s logsource
Rules that don’t match your log sources will fail validation.

Rule Customization

Imported rules may need tuning:
  • Field names - Adjust for your environment
  • Severity - Match your risk tolerance
  • Tags - Add custom tags
  • Exceptions - Tune for your baselines

Tracking Imported Rules

Imported rules are marked with:
  • source: sigmahq - Indicates origin
  • sigmahq_path - Original repository path
This helps track updates when SigmaHQ rules change.

Updating Rules

When SigmaHQ rules are updated:
  1. Sync the repository
  2. CHAD identifies rules with changes
  3. Review changed rules in SigmaHQ > Updates
  4. Choose to update or keep your version
Updating a rule overwrites your local changes. Export custom modifications before updating.

Rule Categories

Core Rules (rules/)

Production-ready detections:
  • Well-tested and validated
  • Low false positive rates
  • Suitable for automated alerting
Recommended for: Production deployment

Threat Hunting (rules-threat-hunting/)

Proactive hunting queries:
  • Broader detection scope
  • Higher false positive potential
  • Requires analyst review
Recommended for: Scheduled hunting, not real-time alerting

Emerging Threats (rules-emerging-threats/)

Rapid response rules:
  • Created for active campaigns
  • May have limited testing
  • Time-sensitive relevance
Recommended for: Active incident response

Best Practices

Only import rules that match logs you’re actually collecting.
Run historical tests on imported rules to understand alert volume.
SigmaHQ severity may not match your risk tolerance. Adjust as needed.
Document changes you make to imported rules for future updates.
Enable auto-sync to get new rules and updates automatically.

Troubleshooting

Sync fails

  • Check network connectivity to GitHub
  • Verify git is installed in the CHAD container
  • Check disk space for repository clone

Rules don’t match logs

  • Verify field mappings are configured
  • Check index pattern matches logsource
  • Test with sample logs

Too many false positives

  • Start with status: stable rules only
  • Use historical testing before deployment
  • Create exception rules for known good activity

Next Steps