Detection Rules Module

Complete

Overview

The Detection Rules module provides the rule engine that powers ThreatOps alert detection. It includes 372 pre-built Sigma-format detection rules covering all 14 MITRE ATT&CK tactics, mapped across 5 SIEM platforms. Rules range from critical severity (ransomware, C2 beacons) to informational (audit events), and tenants can create their own custom rules on top of the engine defaults.

This is a foundational module -- every alert generated by the platform traces back to a detection rule. The rule optimizer service continuously tracks false positive rates to recommend rule tuning.

    372 detection rules across 20+ modules covering Initial Access, Execution, Persistence, Privilege Escalation, Defense Evasion, Credential Access, Discovery, Lateral Movement, Collection, C2, Exfiltration, Impact, and more.
  

What Was Proposed

Pre-built library of Sigma-format detection rules covering all MITRE ATT&CK tactics
Multi-SIEM transpilation targets (Sentinel, Splunk, Elastic, CrowdStrike, Chronicle)
Tenant-specific custom rule creation via API
Rule enable/disable toggling per tenant
Rule statistics and summary reporting
Data source connector catalog
FedRAMP, CISA, and zero-trust compliance-specific rules
Frontend management UI with MITRE tactic filtering

What's Built

372 Sigma detection rules (20+ modules)	✓ Complete
5 SIEM platform targets	✓ Complete
All 14 MITRE ATT&CK tactics covered	✓ Complete
Custom rule CRUD (create, read, update, delete)	✓ Complete
Rule enable/disable API	✓ Complete
Statistics and summary endpoint	✓ Complete
Data sources connector endpoint	✓ Complete
Engine + DB rule merging	✓ Complete
Frontend table with toggle switches	✓ Complete
Expandable rule detail rows	✓ Complete
Gov/compliance rule modules (FedRAMP, CISA, Zero-Trust)	✓ Complete

Architecture

API Router

File: app/routers/detection_rules.py — Prefix: /api/v1/detection-rules

GET    /api/v1/detection-rules/                    # List all rules (engine + DB, filters: severity, mitre_tactic, enabled)
GET    /api/v1/detection-rules/{rule_id}            # Get single rule by ID
POST   /api/v1/detection-rules/                    # Create custom tenant rule
PATCH  /api/v1/detection-rules/{rule_id}           # Update rule (DB or in-memory engine rules)
DELETE /api/v1/detection-rules/{rule_id}           # Delete custom rule
GET    /api/v1/detection-rules/stats/summary       # Rule statistics (counts by severity, tactic, data sources)
GET    /api/v1/detection-rules/connectors/data-sources  # List all configured data source connectors

Rule Loading Architecture

The router merges two rule sources:

Rules Engine — 372 rules loaded from app/rules/ Python modules via get_all_rules(). These are cached in memory on first access.
Database Rules — Tenant-specific custom rules stored in PostgreSQL. Merged at query time; DB rules with IDs matching engine rules are deduplicated.

The PATCH endpoint handles both: for DB rules it updates via ORM, for engine rules it modifies the cached in-memory copy.

Rules Engine Modules

Located at platform/api/app/rules/, the engine contains 20+ Python modules:

Module	Category
`high_severity.py`	High severity cross-tactic detections
`high_identity.py`	Identity and credential attacks
`high_network_endpoint.py`	Network and endpoint threats
`high_remote_ransom.py`	Remote access and ransomware
`high_threat_devops.py`	Threat intelligence and DevOps CI/CD
`high_vuln_endpoint2.py`	Vulnerability exploitation and endpoint
`medium_severity.py` / `medium_part2.py` / `medium_part3.py`	Medium severity detections
`low_severity.py` / `low_auth_account.py` / `low_cloud_devops.py`	Low severity detections
`low_data_firewall.py` / `low_sharepoint_network.py` / `low_vpn_aws.py`	Low severity infrastructure rules
`informational.py`	Informational / audit events
`gov_fedramp.py`	FedRAMP compliance rules
`gov_cisa_pam.py`	CISA PAM compliance rules
`gov_zerotrust.py`	Zero-trust architecture rules
`gov_azure.py`	Azure government rules
`gov_dlp_supply_ir.py`	DLP, supply chain, and IR rules
`data_sources.py`	Data source connector definitions

Routing

Layer	Path
/detection-rules	Frontend list page (Next.js App Router)
/api/v1/detection-rules	API prefix (FastAPI router)

Prerequisites

Rules Engine — app/rules/__init__.py with get_all_rules() and get_data_sources()
Database — PostgreSQL for tenant-specific custom rules
Tenant Middleware — Scopes custom rule creation/queries to tenant

Data Model

Model: app/models/detection_rule.py — Table: detection_rules (extends Base)

Field	Type	Description
`id`	String(36) PK	UUID primary key
`tenant_id`	String(36) nullable	Tenant scope (null for engine rules)
`name`	String(500)	Rule name (required)
`sigma_yaml`	Text	Sigma rule definition in YAML format
`severity`	Enum(RuleSeverity)	critical / high / medium / low / informational
`mitre_tactic`	String(100)	MITRE ATT&CK tactic
`mitre_technique_id`	String(20)	MITRE technique ID
`enabled`	Boolean	Rule enabled/disabled (default: true)
`siem_targets`	JSON	Target SIEM platforms (default: ["sentinel", "splunk"])
`false_positive_notes`	Text	Known FP guidance
`author`	String(255)	Rule author (default: "ThreatOps")
`tags`	JSON	Rule tags (e.g., ["sigma", "production"])
`created_at`	DateTime	Creation timestamp
`updated_at`	DateTime	Last update timestamp

UI Layout

Detection Rules Page

Header — BookOpen icon + "Detection Rules" title + count badge in orange showing filtered rule count
Filter Bar — Severity dropdown (all/critical/high/medium/low)
Rules Table — White rounded card with columns:
- Name — Rule name + rule ID below in small text
- Severity — Color-coded severity badge
- MITRE Tactic — Plain text
- Technique ID — Orange monospace text (e.g., T1059.001)
- SIEM Targets — Colored pills per platform (blue=sentinel, green=splunk, amber=elastic, purple=chronicle, red=crowdstrike)
- Enabled — Toggle switch (green when enabled, grey when disabled). Click sends PATCH to API.
- Author — Text
Expanded Row — Clicking a row expands to show rule details in a slate background panel: MITRE technique + tactic, author, and status.